SecureNet Gateway API Implementation Guide
Iklan
Iklan
SecureNet Gateway API
.
Implementation Guide
Version 4.1.5—01.07.2013
1
SecureNet Gateway Implementation Guide 4.1.5
Table of Contents
1 INTRODUCTION .................................................................................................................................. 4
1.1
How to Use This Document ....................................................................................................... 4
1.2
What is the Gateway? ............................................................................................................... 4
1.3
Service Based Authorization Process ....................................................................................... 5
1.4
How Does the Gateway Work? ................................................................................................. 5
1.5
What is Required to Implement the Gateway? .......................................................................... 5
1.6
Integration and Certification Process ........................................................................................ 5
1.7
Post Integration / Certification ................................................................................................... 6
2 GATEWAY IMPLEMENTATION ......................................................................................................... 7
2.1
Service and SOAP Overview ..................................................................................................... 7
2.2
End Points ................................................................................................................................. 7
2.2.1
Production Endpoints .................................................................................................... 7
2.2.2
Certification Endpoints .................................................................................................. 8
3 INTEGRATED PLATFORMS AND SERVICES .................................................................................. 9
3.1
Platforms .................................................................................................................................... 9
3.2
Feature Restrictions .................................................................................................................. 9
4 METHODS ......................................................................................................................................... 10
4.1
Methods for Standard Payment Transactions [Gateway Services] ......................................... 10
4.2
Methods for Vault Transactions [Gateway Services] .............................................................. 10
4.3
Methods for AutoBill Transactions [Gateway Services] .......................................................... 12
4.4
Reporting Methods for Batch and Transaction Services [Transaction Services] .................... 12
4.5
Reporting Methods for SecureNet Vault and AutoBill Services [Extended Services] ............. 13
4.6
Reporting Methods for P2P Encryption Services [Extended Services] ................................... 14
4.7
Method for Batch Close [Gateway Services] ........................................................................... 14
5 GATEWAY OBJECTS ....................................................................................................................... 15
5.1
Objects for Standard Transactions .......................................................................................... 15
5.1.1
Transaction Object Structure ...................................................................................... 15
5.2
Transaction Object Specification ............................................................................................. 16
5.3
SecureNet Vault / Tokenization Transactions ......................................................................... 18
5.3.1
Vault Specifications ..................................................................................................... 18
5.4
AutoBill Transactions ............................................................................................................... 19
5.4.1
PLAN_AB Object Specifications ................................................................................. 19
6 GATEWAY OBJECT PROPERTIES ................................................................................................. 20
6.1
MERCHANT_KEY ................................................................................................................... 20
6.2
Card ......................................................................................................................................... 21
6.3
Check ....................................................................................................................................... 22
6.4
CUSTOMER_BILL ................................................................................................................... 23
6.5
CUSTOMER_SHIP .................................................................................................................. 24
6.6
ENCRYPTION ......................................................................................................................... 25
6.7
LEVEL2 .................................................................................................................................... 25
6.8
LEVEL3 .................................................................................................................................... 26
6.8.1
LEVEL3PRODUCT ..................................................................................................... 26
i
SecureNet Gateway Implementation Guide 4.1.5
6.9
MPI .......................................................................................................................................... 27
6.10
Auto ......................................................................................................................................... 27
6.11
Petroleum ................................................................................................................................ 28
6.12
Hotel ........................................................................................................................................ 28
6.13
Product .................................................................................................................................... 29
6.14
Service (Restaurant) ................................................................................................................ 30
6.15
UserDefined ............................................................................................................................. 30
6.16
SECONDARY_MERCHANT_KEY .......................................................................................... 30
6.17
Terminal ................................................................................................................................... 31
6.18
Healthcare ............................................................................................................................... 32
6.19
Image ....................................................................................................................................... 32
6.19.1
Checkimage ................................................................................................................ 32
6.20
Transaction Vault Object Summary ......................................................................................... 33
6.20.1
Transaction Vault Object Specification ....................................................................... 33
6.20.1.1
TRANSACTION_VAULT .................................................................................................. 33
6.20.2
ACCOUNT_VAULT ..................................................................................................... 34
6.20.3
CUSTOMER_VAULT .................................................................................................. 35
6.20.4
OPERATIONPARAMETERS ...................................................................................... 36
6.21
AutoBill Transactions ............................................................................................................... 36
6.21.1
PLAN_AB Object Specification ................................................................................... 36
6.21.1.1
PLAN_AB ............................................................................................................................ 36
6.21.1.2
PLAN_AB_EXT .................................................................................................................. 38
6.21.1.3
OPTIONS ............................................................................................................................ 38
6.21.1.4
INSTALLMENT .................................................................................................................. 38
6.21.1.5
RECURRING ...................................................................................................................... 39
6.21.1.6
PAYMENT_AB ................................................................................................................... 40
6.22
Settlement Transactions .......................................................................................................... 41
6.23
Reporting API Services ........................................................................................................... 42
6.24
P2PREQUEST Object ............................................................................................................. 42
6.24.1
P2PREQUEST Object Specification ........................................................................... 43
6.24.2
P2PConfirmationRequest Object Structure ................................................................ 43
6.24.3
P2PConfirmationRequest Object Specification ........................................................... 43
6.24.4
P2PPublicKeyInfo ........................................................................................................ 43
6.25
Reporting Methods for Batch and Transaction Services Input Parameters ........................... 44
7 TRANSACTION REQUEST MESSAGE FORMAT ........................................................................... 45
7.1
Format for Credit Card, Debit Card, EBT, and Stored Value Card Transactions .................... 45
7.2
Format for Electronic Check Transactions .............................................................................. 48
7.3
Transaction Image Request .................................................................................................... 51
7.3.1
Transaction Image Request Message Format for Electronic Signature ..................... 51
8 RESPONSES ..................................................................................................................................... 52
8.1
Standard Transaction Responses Structure ........................................................................... 52
8.1.1
GATEWAYRESPONSE Object Specification ............................................................. 52
8.1.1.1
ABRESPONSE .................................................................................................................. 53
8.1.1.2
TRANSACTIONRESPONSE ........................................................................................... 53
ii
SecureNet Gateway Implementation Guide 4.1.5
8.1.1.3
VAULTACCOUNTRESPONSE ....................................................................................... 55
8.1.1.4
VAULTCUSTOMERRESPONSE .................................................................................... 56
8.1.1.5
P2PRESPONSE ................................................................................................................ 56
8.1.1.6
P2P_PUBLIC_KEY............................................................................................................ 57
8.1.1.7
IMAGERESPONSE ........................................................................................................... 57
8.2
Response Objects for Settlement Transactions ...................................................................... 57
8.2.1
BATCHDATA Object Structure ................................................................................... 57
8.2.1
BATCHDATA Object Specification .............................................................................. 58
8.2.1.1
BATCHDETAIL .................................................................................................................. 58
8.2.1.2
BATCHDATA Message Format ....................................................................................... 58
8.2.1.3
VAULTCUSTOMERRESPONSE .................................................................................... 59
APPENDIX
APPENDIX A: GATEWAY RESPONSE ................................................................................................... 60
APPENDIX B: DEVELOPER NOTES ....................................................................................................... 81
APPENDIX C: REFERENCES .................................................................................................................. 92
iii
SecureNet Gateway Implementation Guide 4.1.5
1 INTRODUCTION
Payment Gateways facilitate electronic commerce by enabling merchants to accept credit cards and electronic checks as methods of payment for goods and services sold. The SecureNet Gateway (Gateway) acts as a bridge between the merchants website/terminal and the financial institutions that process payment transactions. Payment data is collected from the shopper and submitted to the Gateway for real-time authorization.
Authorization is the process of checking the validity and available balance of a customer’s credit card before the transaction can be accepted. To authorize a given credit card transaction, the Gateway transmits the transaction information to the appropriate financial institutions for validation, then returns the response (approved or declined) from the institution to the merchant or customer. The payment Gateway supports real-time and offline requests for credit card authorization. The Gateway also supports electronic check transactions. Merchants can collect customer bank account numbers and routing numbers to pay for purchases.
This document describes how transactions can be submitted to the Gateway for real-time processing.
The Gateway is the recommended integration method for merchants who have the capability to initiate both client and server-side SSL connections. This method offers the merchant a high degree of security and control because transaction data is submitted to the Gateway over a secure server-to-server connection, initiated by the merchant server. Since the merchant server will receive a response directly from the Gateway, the merchant has more control over the response to the end customer.
1.1 How to Use This Document
This document contains hyperlinks which refer the user to the corresponding sections of the document that apply.
Please note that some object names may contain symbols such as underscores.
Document
Method
Objects /
Properties
Request /
Response
1.2 What is the Gateway?
The Gateway is the recommended method of submitting transactions. This method allows the merchants server to securely connect directly to the payment Gateway to submit transaction data. The merchant retains full control of the payment data collection and the user experience. This method requires merchants to be able to initiate and manage secure Internet connections.
4
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
SecureNet Gateway Implementation Guide 4.1.5
1.3 Service Based Authorization Process
Payment authorization utilizes a standards-based Simple Object Access Protocol (SOAP) interface over a Secure
Hyper Text Transfer Protocol (HTTPS) connection to exchange information.
1.4 How Does the Gateway Work?
When using the Gateway, a typical transaction is performed in the following way:
1. The customers program has a reference to the Gateway Service and connects securely to the merchants server to transmit payment information.
2. The merchants server initiates a secure connection to the Gateway and creates the objects as described.
It then initiates a “ProcessTransaction” function by passing the TRANSACTION object along with required data to the Gateway server.
3. The payment Gateway receives and processes the TRANSACTION object.
4. The payment Gateway generates the GATEWAYRESPONSE object and submits it to the merchants server.
5. The merchants server receives and processes the GATEWAYRESPONSE object.
6. Finally, the merchants server communicates the success (or failure) of the authorization to the customer’s web browser or program.
1.5 What is Required to Implement the Gateway?
Merchants must be able to perform the following functions in order to submit transactions to the Gateway:
1. Complete the Gateway Certification Request Form.
2. Create an account in our test environment.
3. Establish a secure socket connection.
4. Provide both server and client-side encryption.
5. Develop code on a web server for the integration to the Gateway utilizing the Gateway service (e.g. for submitting transaction data object and receiving and translating system response object).
6. Securely store the following information in a way that it is configurable: Service URL, SecureNet ID, its corresponding SecureKey, and, optionally, transaction mode (TEST or LIVE). This information will be accessed by the script that submits transactions to the Gateway.
7. Complete the certification process by running test scripts for the transaction scenarios.
1.6 Integration and Certification Process
Once the partner or merchant and SecureNet’s representative have determined that using the API is the right way to integrate to the Gateway the integration process is as follows:
1. If not already done, the merchant should download the “API Package.zip” file from the SecureNet website .
2. The merchant will complete the “Gateway Integration - Test Account Request Form” and sent it to the
SecureNet API Resource Team ( [email protected]
). A test account will be created in the
SecureNet Virtual Terminal application and the merchant will receive three emails detailing access to the account.
3. The API Team will assign a Developer ID that will need to be included in the software/application being integrated.
5
SecureNet Gateway Implementation Guide 4.1.5
4. The API Team will then deliver the Developer ID and some basic code samples (if available for the specified development language). Please note: all code samples are delivered “as is” and are intended to be used as reference. SecureNet does not provide code review services for merchant developers.
5. If the merchant would like to have their integration Certified, the following additional steps would then be required. a. Once the merchant’s development team has completed coding and is ready for certification, an email must be sent to the Certification Team ( [email protected]
) requesting certification scripts. b. Once the merchant’s development team has run the scripts successfully, they will send an email to the Certification Team requesting review of the scripts. The Certification Team will review the scripts and provide feedback to the merchants development team. c. Once all the scripts pass the certification process, the Certification Team will issue a Certification
Letter and send it to the merchant. d. The Certification Letter will be issued for the specific application name and version that was certified.
6. The merchant may now move the system into production and begin using their SecureNet account(s) for payment processing.
1.7 Post Integration / Certification
Once the application integration is complete, the following steps and considerations should be taken into account:
1. The merchant’s development team should change all variables and configuration files to point to the
Production Gateway environment (https://gateway.securenet.com).
2. It is recommended that, before the official release, the development team complete a few production tests using live data. The type and number of tests is at the discretion of the merchant and its development team.
3. Due to the nature of the payment industry, SecureNet reserves the right to make changes to the API and/or the services provided. SecureNet will inform all merchants, via official notification, any changes that will be implemented in future releases. If any of these changes impact the integrated application, the merchant should make the necessary code updates and repeat the integration / certification steps above.
The code changes and retesting must be completed before SecureNet’s official release date. The updated application should be moved into production on the same day as the official SecureNet release.
4. If a Certified application should change in any way SecureNet recommends re-certifying in order to ensure that all existing and new functionality works as intended, and the right version is listed at www.SecureNet.com
(if that option was selected on the certification form).
6
SecureNet Gateway Implementation Guide 4.1.5
This guide explains how to integrate SecureNet into the merchants website or application to process transactions over SecureNets payment Gateway. Transactions could be submitted to the Gateway for processing through:
Structured XML HTTPS POST/REST
XML Web Service/SOAP
WCF Service
2.1 Service and SOAP Overview
The Gateway has implemented Windows Communication Foundation (WCF) as an underlying technology to support authorization capabilities. WCF Services are applications with logic and functions, which are accessible and reusable by means of standard Internet protocols and XML data formats.
The WCF service interface is defined in terms of the XML messages that the service accepts and generates.
Applications consuming WCF Services can be implemented on any platform in any programming language, as long as they can create and consume messages defined for the service interface. The Gateway has adopted Simple
Object Access Protocol (SOAP) as the solution for initiating RPC-based authorization requests. SOAP is a lightweight protocol intended for exchanging structured information in a distributed environment. The protocol uses
XML technologies to define an extensible messaging framework to provide a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model or language, platform, and other implementation-specific semantics.
The Gateway API integration can also be completed using REpresentational State Transfer (REST) architecture.
REST is less strongly typed than its counterpart, SOAP . The REST language is based on the use of nouns and verbs, and has an emphasis on readability. Unlike SOAP, REST does not require XML parsing and does not require a message header to and from a service provider . REST error handling is also different from that used by
SOAP. SOAP can have user defined error messages while REST requires the use of HTTP error handling.
To implement the Gateway service, a developer integrates the application to the API that performs the following:
1. Securely obtain all the information needed to process a transaction.
2. Create a program to consume the Gateway service.
NOTE: The SecureNet Gateway will only accept transactions on port 443 via https. This request object will include all system variables mentioned in the tables below.
3. Receive and process the response from the Gateway to display the appropriate result to the end-user.
2.2.1
Production Endpoints
Transaction API (Gateway Services)
https://gateway.securenet.com/API/Gateway.svc/webHttp (XML POST / REST)
https://gateway.securenet.com/API/Gateway.svc/soap (XML Web service / SOAP)
Extended Transaction Functionality API (Extended Services)
https://gateway.securenet.com/API/data/service.svc/webHttp (XML POST / REST)
https://gateway.securenet.com/API/data/service.svc/soap (XML Web service / SOAP)
7
SecureNet Gateway Implementation Guide 4.1.5
Extended Transaction Process API (Transaction Services)
https://gateway.securenet.com/API/data/transaction.svc/webhttp (XML POST / REST)
https://gateway.securenet.com/API/data/transaction.svc/soap (XML Web service / SOAP)
Global XSD
https://gateway.securenet.com/api/validationobject.xsd
WSDL
https://gateway.securenet.com/API/Gateway.svc?wsdl
(Gateway Services)
https://gateway.securenet.com/API/Data/SERVICE.svc?wsdl
(Extended Services)
https://gateway.securenet.com/API/Data/TRANSACTION.svc?wsdl
(Transaction Services)
2.2.2
Certification Endpoints
Transaction API (Gateway Services)
https://certify.securenet.com/API/Gateway.svc/webHttp (XML POST / REST)
https://certify.securenet.com/API/Gateway.svc/soap (XML Web service / SOAP)
Extended Transaction Functionality API (Extended Services)
https://certify.securenet.com/API/data/service.svc/webHttp (XML POST / REST)
https://certify.securenet.com/API/data/service.svc/soap (XML Web service / SOAP)
Extended Transaction Process API (Transaction Services)
https://certify.securenet.com/API/data/transaction.svc/webhttp (XML POST / REST)
https://certify.securenet.com/API/data/transaction.svc/soap (XML Web service / SOAP)
WSDL
https://certify.securenet.com/API/Gateway.svc?wsdl
(Gateway Services)
https://certify.securenet.com/API/Data/SERVICE.svc?wsdl
(Extended Services)
https://certify.securenet.com/API/Data/TRANSACTION.svc?wsdl
(Transaction Services)
Global XSD
https://certify.securenet.com/api/validationobject.xsd
8
SecureNet Gateway Implementation Guide 4.1.5
3 INTEGRATED PLATFORMS AND SERVICES
3.1 Platforms
Ceridian
Certified Platform Services Available
Stored Value
Certegy
First Data Nashville
PaymentTech Netconnect (Tampa)
SecureNet ACH Services
SecureNet FrontEnd
TSYS (VITAL)
Supported Environment
Retail
Moto
E-Commerce
ACH verification
Credit Card, Pin Debit
Credit Card, Stored Value, Pin Debit
PPD, CCD, TEL, & WEB only
Retail
Restaurant
Moto
Ecommerce
Retail
Restaurant
Moto
Ecommerce
Petroleum
Lodging/Hotel
Car Rental
Pre-Note, ACH processing
Credit Card, Pin Debit, Pin-less Debit, EBT Retail
Restaurant
Moto
Ecommerce
Credit Card, Pin Debit
PPD, CCD, WEB, TEL, ARC, BOC, POP,
& POS
Retail
Restaurant
Moto
Ecommerce
Feature Platform Availability
SecureNet Vault All
AutoBill All
ACH
E2E encryption (Software Based)
E2E encryption (Hardware Based)
Soft Descriptor
Level 3
SecureNet
All
All
SecureNet FrontEnd
TSYS
First Data only
Other Restrictions
MOTO merchants only
SecureNet Vault Service is required
MOTO merchants only
RETAIL and MOTO merchants only
Available for IDTECH certified and fulfilled by SecureNet hardware only
Acquirer’s discretion
Not available on TSYS, SecureNet
Frontend or Paymentech
9
SecureNet Gateway Implementation Guide 4.1.5
4 METHODS
4.1 Methods for Standard Payment Transactions [Gateway Services]
Method Name Operation Description Objects
ProcessTransaction This method can be used to perform the following operations:
Process a regular
Transaction
Process Transaction by Customer ID
Process Transaction by Secondary ID
(SECONDARY_MER
CHANT_KEY
Process Transaction by Transaction ID
Other transaction calls
Please refer to the
TRANSACTION_SERVI
CE values for more information
UpdateTransaction Used to save electronic
Signature.
To perform any of these operations using the Process Transaction method, the input
Object(s) should be TRANSACTION , the
TRANSACTION_SERVICE in the
TRANSACTION object must be set and the
MERCHANT_KEY should be supplied within
TRANSACTION object.
For the Process Transaction by Secondary
ID operation, the
SECONDARY_MERCHANT_KEY should be supplied inside the
SECONDARY_MERCHANT_KEY property of the TRANSACTION object. No card/check information should be provided in the CARD/CHECK object.
The Process Transaction by Customer ID operation will process transaction(s) ondemand for the stored Customer Record.
For Card Transactions: The CARDCODE and ADDITIONALINFO objects, which are part of the CARD object, assigned to the
TRANSACTION object, are used to process card transactions.
For ACH Transactions: The SECCODE ,
CHECKNUM, and ADDITIONALINFO objects, which are part of the CHECK object, assigned to the TRANSACTION object, are used to process ACH transactions.
Store the electronic signature
Input Object(s):
TRANSACTION
Output Object(s):
GATEWAY
RESPONSE
Input Object(s):
TRANSACTIONIMAGE
Output Object(s):
IMAGERESPONSE
Reference
Available through:
Gateway
Services
Available through:
Gateway
Services
4.2 Methods for Vault Transactions [Gateway Services]
Method Name
ProcessAccount
Operation
This method can be used to perform the following operations:
Add Vault Account
Update
Account
Delete
Account
Description Required Objects
To perform any of the operations using the ProcessAccount method, the TRANSACTION_VAULT should be used as the input object. All account information to be added should be passed inside
ACCOUNT_VAULT object and
MERCHANT_KEY inside
TRANSACTION_VAULT object. The vault inside the
OPERATIONPARAMETERS object should be set for
Add/Update/Delete.
Input Object(s):
TRANSACTION_VAULT
Output Object(s):
GATEWAYRESPONSE
Reference
Available through:
Gateway
Services
10
SecureNet Gateway Implementation Guide 4.1.5
Method Name
ProcessCustomer
ProcessCustomerAnd
Account
ProcessVaultTransacti on
Operation Description Required Objects
This method can be used to perform the following operations:
Add Vault Customer
Update
Customer
Delete
Customer
Add Vault Customer
And Account
Update Vault Customer
And Account
Process Transaction
Add Customer and
Account
To perform any of the operations using this ProcessCustomer method, the TRANSACTION_VAULT should be used as the input object. The
ACTIONCODE inside
OPERATIONPARAMETERS object should be set for Add/Update/
Delete. All customer information to be added should be passed inside
CUSTOMER_VAULT object and
MERCHANT_KEY inside
TRANSACTION_VAULT object for the add operation.
CUSTOMERID should be passed inside the ACCOUNT_VAULT object and MERCHANT_KEY inside
TRANSACTION_VAULT object for the Update Operation.
Required Object:
TRANSACTION_VAULT
Input Object(s):
< TRANSACTION_VAULT >
CUSTOMER_VAULT
ACCOUNT_VAULT
MERCHANT_KEY
Output Object(s):
GATEWAYRESPONSE
To perform any of these operations using the
ProcessCustomerAndAccount method, the
TRANSACTION_VAULT should be used as the input object. The
ACTIONCODE inside
OPERATIONPARAMETERS object should be set for Add/Update operation. All customer information to be added should be passed inside
CUSTOMER_VAULT object, account information inside
ACCOUNT_VAULT object and
MERCHANT_KEY inside
TRANSACTION_VAULT object.
Input Object(s):
TRANSACTION_VAULT
CUSTOMER_VAULT
ACCOUNT_VAULT
OPERATIONPARAMETERS
MERCHANT_KEY
Output Object(s):
GATEWAYRESPONSE
This is a method to process transaction on-demand and to store a new Customer and account in
Vault. ReportingAPImethods property value inside
TRANSACTION object should be set for Add MERCHANT_KEY should be supplied within
TRANSACTION_VAULT object, customer information to be added should be supplied inside
CUSTOMER_VAULT , account information to be added should be supplied inside ACCOUNT_VAULT and transaction information except
MERCHANT_KEY should be supplied inside TRANSACTION object.A
Input Object(s):
TRANSACTION_VAULT
CUSTOMER_VAULT
ACCOUNT_VAULT
TRANSACTION
MERCHANT_KEY
Output Object(s):
GATEWAYRESPONSE
Reference
Available through:
Gateway
Services
Available through:
Gateway
Services
Available through:
Gateway
Services
11
SecureNet Gateway Implementation Guide 4.1.5
Method Name Operation Description Required Objects Reference
CopyVaultAccount CopyVaultAccount This method allows an existing Vault account to copy from one customer to another and from one SecureNet
ID to another
Input parameters:
SOURCE_MERCHANT_KEY
( MERCHANT_KEY ),
SOURCE_ACCOUNT_VAUL
T ( ACCOUNT_VAULT ),
TARGET_MERCHANT_KEY
( MERCHANT_KEY ),
TARGET_ACCOUNT_VAULT
( ACCOUNT_VAULT ),
CREATE_CUSTOMER
(integer, 0—do not create,
1—create),
CHANGE_ACCOUNT_INFO_
TO_TARGET (integer, 0—do not change target account,
1—change target account).
Output Object(s):
GATEWAYRESPONSE
Available through:
Gateway
Services
4.3 Methods for AutoBill Transactions [Gateway Services]
Method Name Operation Description Objects Reference
AddABAccount Add AutoBill
Account
Use this method to add an
AutoBill Account
Input Object(s):
PLAN_AB
Output Object(s):
GATEWAYRESPONSE
UpdateABAccount Update AutoBill
Account
Use this method to update an AutoBill Account
Input Object(s): PLAN_AB
Output Object(s):
GATEWAYRESPONSE
UpdateABSchedule Update AutoBill
Schedule
Use this method to update an AutoBill Schedule
Input Object(s):
PLAN_AB
Output Object(s): GATEWAYRESPONSE
ProcessABAccount Add/Update/Delete
AutoBIll Account with UDFs
Use this method to
Add/Update/Delete
AutoBIll Account with
UDFs
Input Object(s):
PLAN_AB_EXT
,
OPERATIONPARAMETERS
Output Object(s):
GATEWAYRESPONSE
Available through:
Gateway Services
Available through:
Gateway Services
Available through:
Gateway Services
Available through:
Gateway
Services
4.4 Reporting Methods for Batch and Transaction Services [
Transaction Services]
Method Name
GetBatchTransactions
Description Objects
Method to retrieve the
TRANSACTIONRESPONSE data for a particular Batch
If BatchId = 0 captured transactions from the unclosed batch will be returned
For all other values in BatchId, transactions specific to that particular batch will be returned
Input parameters: MERCHANT_KEY and BatchId
Output parameter: Array of
TRANSACTIONRESPONSE objects
Reference
Available through:
Transaction Services
12
SecureNet Gateway Implementation Guide 4.1.5
Method Name Description
GetTransactionByOrderID Method to retrieve the
TRANSACTIONRESPONSE data by
Order ID when Transaction ID is not available
Transactions with basic validation errors are not stored and returned in this method
GetTransactionByTransac tionID
Method to retrieve the
TRANSACTIONRESPONSE data by
Transaction ID
GetCurrentBatchID
GetTransactions
Objects
Input Object(s): MERCHANT_KEY and OrderID
Output Object(s):
TRANSACTIONRESPONSE
Reference
Available through:
Transaction Services
This method will return the last closed
Batch ID
Method to retrieve transaction data for transactions processed during a specific period of time
Input Object(s):
MERCHANT_KEY and TransactionID
Output Object(s):
TRANSACTIONRESPONSE
Input Object(s):
MERCHANT_KEY
Output Object(s): BatchId
Input parameters:
MERCHANT_KEY ,
StartDate, EndDate, ExcludeDate,
CustomerID, Amount, RBOnly
Output Object(s): Array of
TRANSACTIONRESPONSE objects
Available through:
Transaction Services
Available through:
Transaction Services
Available through:
Transaction Services
4.5 Reporting Methods for SecureNet Vault and AutoBill Services [
Extended Services
]
Method Name Description Required Objects Reference
GetABAccount
GetABAccounts
GetVaultCustomers
Method to retrieve a single AutoBill accounts
Method to retrieve All AutoBill accounts
Input Object(s):
Output Object(s):
PLAN_AB
PLAN_AB
Input Object(s): MERCHANT_KEY and
CustomerID
Output Object(s): PLAN_AB
Available Through:
Extended Services
Available Through:
Extended Services
Method to retrieve a Vault Customer
Input Object(s):
MERCHANT_KEY and
CustomerID
Available Through:
Extended Services
Output Object(s):
CUSTOMER_VAULT
GetVaultAccountByCustomer Method to retrieve Vault Accounts by
Customer ID
Input Object(s):
CustomerID
MERCHANT_KEY
Output Object(s): Array of
ACCOUNT_VAULT objects
and Available Through:
Extended Services
GetVaultAccount Method to retrieve a Vault Account
GetVaultRecordByCardNo
GetP2PKey
ConfirmP2PKey
Method to retrieve Vault Accounts by
Card Number
Method to request the current active primary or active secondary P2P
Encryption Key
Method to request confirmation and activation of a new P2P Encryption key.
Input Object(s): MERCHANT_KEY ,
CustomerID, and PaymentID
Output Object(s): ACCOUNT_VAULT
Available Through:
Extended Services
Input Object(s):
MERCHANT_KEY and
CardNumber
Output Object(s):
Array of
ACCOUNT_VAULT objects
Available Through:
Extended Services
Input Object(s):
P2PREQUEST
Output Object(s):
P2PResponse
Available Through:
Extended Services
Input Object(s):
P2PConfirmationRequest
Output Object(s):
P2PResponse
Available Through:
Extended Services
13
SecureNet Gateway Implementation Guide 4.1.5
Method Name
GetABAccounts_Ext
GetABAccount_Ext
Description
Method to retrieve all AutoBill
Accounts with UserDefined Values
Method to retrieve a single AutoBill
Account with UserDefined Values
Required Objects
Input Object(s):
PLAN_AB_EXT
Output Object(s):
PLAN_AB_EXT
Input Object(s):
MERCHANT_KEY ,
CustomerID and PLAN_AB_EXT
Output Object(s):
PLAN_AB_EXT
Reference
Available Through:
Extended
Services
Available Through:
Extended
Services
4.6 Reporting Methods for P2P Encryption Services [Extended Services
]
Method Name
CreateP2PKey
ConfirmP2PKey
GetP2PKey
Description
Method to Request a new P2P
Encryption Key
Method to Request confirmation and activation of a new P2P
Method to request the current, primary
P2P Encryption Key.
Required Object(s)
Input Object(s):
P2PRequest
Output Object(s):
P2PResponse
Input Object(s):
P2PConfirmationRequest
Output Object(s):
P2PResponse
Input Object(s):
P2PRequest
Output Object(s): P2PResponse
Reference
Available Through:
Extended Services
Available Through:
Extended Services
Available Through:
Extended Services
4.7 Method for Batch Close [Gateway Services]
Method Name
CloseBatch
Description
Close out the batch for settlement based on SecureNet ID
Required Object(s)
Input Object(s):
MERCHANT_KEY
Output Object(s): BATCHDATA
Reference
Available through:
Gateway Services
14
SecureNet Gateway Implementation Guide 4.1.5
The objects submitted to the Gateway are shown below. Parameters for each object are described in this document.
5.1 Objects for Standard Transactions
This section outlines the various high level sections within the Transaction Request Object for Standard
Transactions.
5.1.1
Transaction Object Structure
This object defines information that can be submitted to the Gateway for real-time transaction processing.
TRANSACTION
MERCHANT_KEY
CARD
CHECK
CUSTOMER_BILL
CUSTOMER_SHIP
ENCRYPTION
LEVEL2
LEVEL3
MPI
AUTO
PETROLEUM
HOTEL
PRODUCT
SERVICE
USERDEFINED
SECONDARY_MER-
CHANT KEY
TERMINAL
HEALTHCARE
IMAGE
15
SecureNet Gateway Implementation Guide 4.1.5
5.2 Transaction Object Specification
The parameters defined below are found in the TRANSACTION object and are assigned to the instance of this serialized object and passed to the web method “ ProcessTransaction ” to complete an authorization. The
TRANSACTION Object can be used through Gateway Services and Transaction Services.
Object Name
TRANSACTION
Description
The parameters defined below are assigned to the instance of this serialized object and passed to the web method “ ProcessTransaction to complete an authorization.
This object is also passed inside the
TRANSACTION_VAULT object for
ProcessVaultTransaction method while processing a transaction and adding vault account/customer.
MERCHANT_KEY This object is used to verify merchant before processing any transaction and is required for any operation.
CARD This CARD payment object contains
Card information like Card number, expiry date.
Constraints
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
Methods Used
ProcessTransaction
ProcessVaultTransaction
Reference
Available Through:
Gateway Services
Transaction Services
All methods All
CHECK
CUSTOMER_BILL
CUSTOMER_SHIP
ENCRYPTION
LEVEL 2
Check payment object is required for electronic check transactions and contains information corresponding checking or saving account.
This object contains Customer
Billing address and phone number and is required for Ecommerce.
This object contains the customers shipping information, like name and address.
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
This object is used for P2P
Encryption.
This Object is used for Level 2 data.
Level2 Transactions normally involve corporate cards issued from a U.S Bank.
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
ProcessTransaction
ProcessVaultTransaction
ProcessAccount
ProcessCustomerAndAcc ount
CopyVaultAccount
ProcessTransaction
ProcessVaultTransaction
ProcessAccount
ProcessCustomerAndAcc ount
CopyVaultAccount
ProcessTransaction
ProcessVaultTransaction
ProcessAccount
ProcessCustomerAndAcc ount
CopyVaultAccount
ProcessTransaction
ProcessVaultTransaction
ProcessAccount
ProcessCustomerAndAcc ount
CopyVaultAccount
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
16
SecureNet Gateway Implementation Guide 4.1.5
Object Name
LEVEL 3
MPI
AUTO
Description Constraints
This Object is used for Level 3 data.
Purchases that qualify as level 3 transactions are generally made with government credit cards or corporate cards.
NOTE: Level 3 is only available to merchants on First Data Nashville platform and only for E-
COMMERCE, RETAIL and MOTO transactions.
All restrictions as defined in the
Request Object
Specs apply
The Object describes Merchant
Plug-in Indicator for 3D Secure
Transactions.
This object is used for Rental
Industry and includes rental-related information, like city rented, returned in and return times, etc.
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
Methods Used
ProcessTransaction
ProcessVaultTransaction
Reference
Available Through:
Gateway Services
Transaction Services
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
PETROLEUM
HOTEL
PRODUCT
SERVICE
USERDEFINED
SECONDARY_MER
CHANT_KEY
This object is used for Petroleum industry only and includes information like number of gallons, unit price, etc.
The object is used for Hotel industry only and includes information, like check-in, check-out times, room rate, etc.
This object contains individual product information, like product description, amount, quantity, etc.
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
This object is used for the
Restaurant industry and contains gratuity amount and server number.
This object contains 50 user defined fields and allows merchants to store additional data along with transaction information.
NOTE: User defined fields are not intended to and must not be used to capture personally identifying information, like name, address, credit card number, social security number, driver’s license number, state-issued identification number, passport number, and card verification numbers.
This object is similar to the
MERCHANT_KEY Object and is used for processing transactions across various SecureNet IDs using information from the Vault linked to the Primary SecureNet ID.
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
All restrictions as defined in the
Request Object
Specs apply
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
ProcessTransaction
ProcessVaultTransaction
ProcessTransaction
ProcessVaultTransaction
ProcessTransaction
ProcessVaultTransaction
ProcessTransaction
ProcessVaultTransaction
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
17
SecureNet Gateway Implementation Guide 4.1.5
Object Name
TERMINAL
HEALTHCARE
IMAGE
Description
This is Object is used to provide terminal information for each transaction. It is applicable for ACH
(POS SEC Code) and Ceridian
Transactions.
This is Object is used to provide healthcare information for each transaction.
This is Object is used to provide
CHECK21 image information and
Credit Card signature information.
Constraints
All restrictions as defined in the
Request Object
Specs apply
Methods Used
ProcessTransaction
ProcessVaultTransaction
Reference
Available Through:
Gateway Services
Transaction Services
All restrictions as defined in the
Request Object
Specs apply
Byte array, should be deserializable to image
ProcessTransaction
ProcessVaultTransaction
ProcessTransaction
ProcessVaultTransaction
Available Through:
Gateway Services
Transaction Services
Available Through:
Gateway Services
Transaction Services
5.3 SecureNet Vault / Tokenization Transactions
SecureNet Vault is SecureNets Payment Card Industry Data Security Standard (PCI-DSS) compliant solution for storing information for credit cards, electronic checks, and Pin-less debit cards. It is a virtual database hosted by and at SecureNet on secure servers. Through tokenization, SecureNet Vault allows tokens to be created for credit card numbers. These tokens are then used for transactions instead of the actual credit card number. Multiple credit card information can be stored for a single individual in the form of tokens. Only the credit card number and expiry date will be stored in SecureNet Vault. The security code cannot be stored as it is against PCI compliance to do so.
This means that track data cannot be stored either. In addition, debit cards are excluded, since it is against PCI compliance to store the pin and payments cannot be processed without the pin.
This section outlines the various high level Objects within the SecureNet Vault.
5.3.1
Vault Specifications
TRANSACTION VAULT
ACCOUNT_VAULT
CUSTOMER_VAULT
MERCHANT_KEY
OPERATIONPARAMETERS
TRANSACTION
Object Name
ACCOUNT_VAULT
CUSTOMER_VAULT
Description Constraints
Contains account information for a specific customer within the SecureNet
Vault
Account should be set up to use the SecureNet
Vault
Methods Used
Methods using this object include:
ProcessAccount
ProcessCustomer
ProcessCustomerAndAccount
ProcessVaultTransaction
CopyVaultAccount
Contains customer information for a specific customer within the SecureNet
Vault
Must be enabled to use the
SecureNet Vault
Methods using this object include:
ProcessCustomer
ProcessCustomerAndAccount
ProcessVaultTransaction
Reference
Gateway Services ,
Extended
Transaction
Services
Gateway Services ,
Extended
Transaction
Services
18
SecureNet Gateway Implementation Guide 4.1.5
Object Name
OPERATIONPARAMETERS
TRANSACTION_VAULT
Description
This object is used to specify operation type (Add, Update, or Delete)
Constraints
Must be enabled to use the
SecureNet Vault
Methods Used
Methods using this object include:
ProcessVaultTransaction
ProcessAccount
ProcessCustomer
ProcessCustomerAndAccount
Used to process a
SecureNet Vault transaction
Must be enabled to use the
SecureNet Vault
Methods using this object include:
ProcessAccount
ProcessCustomer
ProcessCustomerAndAccount
ProcessVaultTransaction
Reference
Gateway Services ,
Gateway Services ,
This section outlines various high level objects within the PLAN_AB Object for AutoBill Transactions.
5.4.1
PLAN_AB Object Specifications
PLAN_AB
MERCHANT_KEY
INSTALLMENT
RECURRING
SCHEDULE
Object Name
PLAN_AB
MERCHANT_KEY
Description
This object defines the information that can be submitted to the
Gateway for AutoBill transaction processing.
Constraints
Must be enabled to use
AutoBill.
Methods Used
Methods using this object include:
AddABAccount
UpdateABAccount
UpdateABSchedule
GetABAccount
GetABAccounts
Applicable to
Gateway services ,
Extended Services
This object is used to verify the merchant before processing any transaction and is required for every operation.
All methods Gateway services ,
Extended Services
Transaction Services
19
SecureNet Gateway Implementation Guide 4.1.5
Object Name
INSTALLMENT
RECURRING
SCHEDULE
PLAN_AB_EXT
Description
This object contains information on
Customer’s installment plan.
This object contains information on
Customer’s recurring payment plan.
This object contains an array of PAYMENT_AB
Constraints
Must be enabled to use
AutoBill.
Must be enabled to use
AutoBill.
Must be enabled to use
AutoBill.
This object contains
PLAN_AB and the
USERDEFINED objects
Must be enabled to use
AutoBill.
Methods Used
Methods using this object include:
AddABAccount,
UpdateABAccount
UpdateABSchedule
GetABAccount
GetABAccounts
Methods using this object include:
AddABAccount
UpdateABAccount
UpdateABSchedule
GetABAccount
GetABAccounts
Methods using this object include:
AddABAccount
UpdateABAccount
UpdateABSchedule
GetABAccount
GetABAccounts
Methods using this object include:
ProcessABAcount
GetABAccount_Ext
GetABAccounts _ Ext
Applicable to
Gateway services
Extended Services
Gateway services
Extended Services
Gateway services
Extended Services
Gateway services
Extended Services
6 GATEWAY OBJECT PROPERTIES
6.1 MERCHANT_KEY
This object is used to verify merchant before processing any transaction and is required for any operation.
XML Tag
<MERCHANT_KEY>
Data Type /
Max Length Required
Required
<GROUP_ID>
<SECUREKEY>
Integer / 15 False
String / 50 True
Description
This object is used to verify the merchant before processing any transaction and is required for every operation
SecureNet Group ID. Not applicable to all merchants, should be provided by SecureNet
Please contact us for more information
Case-sensitive unique SecureKey is associated with corresponding SecureNet ID, used to
Reference links
Gateway Services
Transaction Services
Extended Services
20
SecureNet Gateway Implementation Guide 4.1.5
<SECURENETID>
</MERCHANT_KEY>
Integer / 8 True
<ADDITIONALINFO> String / 250 Required if
METHOD=EBT authenticate the merchant and is required for each submitted transaction
7-digit unique SecureNet ID provided by SecureNet to identify the merchant and is required for each submitted transaction.
If a SecureNet ID is needed contact SecureNet
For EBT transactions only. String format: 11 (EBT indicator) followed by a 7-digit FNS number (leftjustified, space-filled, if FNS is less than 7 digits)
.
6.2 Card
Card payment object contains card information, like card number, expiration date, and can be any of the following:
Credit Card, Check Card, Debit Card, or Stored Value Card.
XML Tag
<CARD>
<CARDCODE>
<CARDNUMBER>
Data
Type /
Max
Length
String /
24
Required
String / 4 Required for all E-commerce and MOTO transactions
May also be manually keyed-in for Retail transactions for added security and lower interchange rate
Methods Used
Required for Card-Not-
Present transactions and manually keyed-in transactions when
TRACKDATA is not present.
Full card number is required for all regular transactions.
The last 4 digits of the card number are required for
VOID and PRIOR_AUTH transactions.
Not required when processing transactions for stored customer records, i.e.
Vault transactions.
Card number, 16 digits long for
Visa, MasterCard and Discover,
15 digits long for American
Express
This value may not contain spaces, non-numeric characters, or dashes
Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for
Transaction Object Specification.
A code that is printed on the back of a card. Used as partial assurance that the card is in the buyer’s possession. This code is 3 digits long for Visa, MasterCard, and Discover, and 4 digits long for
American Express.
Not required but could be used for securing credit card transactions by means of card security code validation. If card security code data is submitted, the issuer verifies whether the number matches the number assigned to the card.
21
SecureNet Gateway Implementation Guide 4.1.5
<EXPDATE>
<KSN>
<PINBLOCK>
<TRACKDATA>
</CARD>
String /
19
String /
16
String /
200
<ADDITIONALINFO> String/
250
String / 4 Required for Card-Not-
Present transactions and manually keyed-in transactions when
TRACKDATA is not present.
Required if METHOD = DB Debit Only—Unaltered KSN
Number from PIN pad
Required if METHOD = DB Debit Only—PinBlock from PIN pad
Required for Card-Present
Credit Card transactions, Pin
Debit transactions, and EBT
(Not Voucher Clear) transactions.
This field contains information encoded from a valid magnetic stripe
It includes information such as
Primary Account Number and
Expiration Date
Refer to Appendix for more information.
Optional.
Required if METHOD= EBT and Transaction Type
Code=0300 for Voucher
Clear Transactions.
A valid card expiration date, which is not in the past
Format: MMYY
Example: 1012 represents
October 2012
00—No credit card account verification, default*
01—Credit card account verification*
11 followed by a 15-character long left-justified space-filled EBT
Voucher number **
02—Updates the EXPDATE of credit card during
ProcessTransaction by Customer
ID, if expiration date supplied is a future date for the PaymentID
*Applicable only when adding a new Account to the SecureNet Vault.
**For EBT Voucher Clear transactions only.
6.3 Check
Check payment object is required for electronic check transactions and contains information on corresponding checking or savings account.
XML Tag
<CHECK>
Data Type /
Max Length Required
<ABACODE> String / 9
<ACCOUNTNAME> String / 50
<ACCOUNTNUM> String / 17
True
True
True
Notes
A 9-digit value representing Bank
Routing/ABA Number to identify the Bank.
Account Holder Name is required for Check
Verification transactions
If left blank—will default to Customer Name from CUSTOMER_BILL object
If Customer Name is blank—an error will be returned
Indicated the Account Number to be charged
Reference
Refer to Section 4.1 and
4.2 for methods and section 7.1 for Transaction
Object Specification.
22
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length
<ACCOUNTTYPE> String / 8
<BANKNAME>
<CHECKNUM>
<MICRDATA>
<SECCODE>
</CHECK>
String / 50
String / 20
String / 400
String / 20
<ADDITIONALINFO> String / 250
True
Required Notes for the transaction, an all-numeric value.
Type of Bank Account, i.e. SAVINGS,
CHECKING,BCHECK, BSAVE
False
Required if
SECCODE is BOC,
POS, or ARC
Name of Account Holders’ Bank.
Check Number
False
True
Used only for
METHOD =
ECHECK
MICR Data Read from Check reader
ACH Transaction Classification—The
Standard Entry Class (SEC) code is a three letter code that identifies the nature of the
ACH entry, like: PPD, WEB, TEL, etc.
Refer to Appendix
00—No check verification, default
01—Check verification with Certegy*
02—Pre-Note with ACH Provider**
Reference
Case sensitive
Case sensitive
*Merchant should be enabled with Certegy, please contact SecureNet for more information. For Transaction Type Code 0000—AUTH_ONLY or 0100—
AUTH_CAPTURE data will be sent for processing only if check verification returns an APPROVED status from Certegy. If Transaction Type Code is 0700—
VERIFICATION data will be sent to Certegy for check verification ONLY, no transaction will be sent for processing.
**Set transaction type code to 0700—VERIFICATION . Data will be sent to ACH Provider for Pre-Noting ONLY, no transaction will be sent for processing.
Pre-Note CANNOT be used in conjunction with Transaction Type Codes 0000—AUTH_ONLY or 0100—AUTH_CAPTURE .
6.4 CUSTOMER_BILL
This object contains the customers billing information, like billing address and telephone number, and is required for all E-Commerce transactions.
ML Tag
<CUSTOMER_BILL>
<ADDRESS>
<CITY>
<COMPANY>
<COUNTRY>
Data Type /
Max Length
String / 60
String / 40
String/50
String / 60
Required Notes Reference
Refer to Section 4.1 and
4.2 for methods and section 7.1 for
Transaction Object
Specification.
Alpha numeric only, no special characters
True for E-
Commerce transactions
Billing street address. Together with Zip Code can be used for securing credit card transactions by means of the Address Verification System
(AVS), result of AVS check will be coming back in AVS_RESULT_CODE variable of the
TRANSACTIONRESPONSE object.
Billing City True for E-
Commerce transactions
False Billing Company
False Billing Country
Alpha number only, no special characters
Alpha number only, no special characters
23
SecureNet Gateway Implementation Guide 4.1.5
ML Tag
<EMAIL>
Data Type /
Max Length Required
String / 255 False
<EMAILRECEIPT> String/5 False
<FIRSTNAME>
<LASTNAME>
<PHONE>
<STATE>
<ZIP>
</CUSTOMER_BILL
>
String / 50
String / 50
String / 25
String / 40
String / 20
False
False
False
False
True for E-
Commerce transactions
Notes
Cardholder’s Email address
Has to be specified if Email receipt is to be sent to the Cardholder for successful transaction
Merchants can choose to send a Gateway generated email receipt to customers, who provide an email address with their transaction
The email receipt includes a summary and results of the transaction. Possible values:
TRUE / FALSE
If no email is provided value is considered
FALSE
Contains the first name of the customer associated with the billing address for the transaction
Contains the last name of the customer associated with the billing address for the transaction
Contains the phone number of the customer associated with the billing address for the transaction
Billing State
Billing Zip Code
If full address is not provided, it is advised to provide at least the ZIP for more security
Reference
Valid email address
Upper case values only
6.5 CUSTOMER_SHIP
(completely optional)
This object contains the customers shipping information, like name and address.
XML Tag
<CUSTOMER_SHIP>
Data Type /
Max Length Required
<ADDRESS>
<CITY>
<COMPANY>
<COUNTRY>
<FIRSTNAME>
<LASTNAME>
String / 50
String / 40
String / 50
String / 50
String / 50
String / 50
<STATE>
<ZIP>
</CUSTOMER_ SHIP>
String / 40
String / 20
False
False
False
False
False
False
False
False
Notes
Customers shipping Street Address
Customers shipping City
Customers shipping Company
Customers shipping Country
Shipping First Name
Shipping Last Name
Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for
Transaction Object Specification.
Shipping State
Shipping Zip Code
24
SecureNet Gateway Implementation Guide 4.1.5
6.6 ENCRYPTION
This object is used for P2PEncryption.
XML Tag
<ENCRYPTION>
</ ENCRYPTION >
Data Type /
Max Length Required
<ENCRYPTIONMODE> Integer Yes software base
Notes
0—No Encryption
1—P2PE software based
2—P2PE Hardware based use for encryption/ decryption. This value represents either the Primary or Secondary active P2P Public Key
Yes
Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for
Transaction Object Specification.
6.7 LEVEL2
This Object is used for Level 2 data. Level 2 transactions normally involve corporate cards issued from a U.S Bank.
XML Tag
<LEVEL2>
<DUTY>
<FREIGHT>
<PONUM>
<TAX>
<TAXFLAG>
Data Type /
Max Length Required
Decimal
Decimal
String/50
Decimal
String
True *
True *
True *
True *
True *
Notes
Duty Amount
Freight Amount
Purchase Order
Tax amount
Tax Inclusion
Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for Transaction Object Specification.
0 = Tax not included
1 = Tax included
2 = Tax exempt
</LEVEL2>
*Required for Level 2 processing, if this data is not provided—transaction will still be processed as Level 1.
25
SecureNet Gateway Implementation Guide 4.1.5
6.8 LEVEL3
This object is used for Level 3 data. Purchases that qualify as Level 3 transactions generally are made with government credit card or corporate cards. It is optional to submit the data as part of the transaction.
NOTE: Level 3 is only available to merchants on First Data Nashville platform and only for E-
Commerce, Retail, and MOTO transactions.
<LEVEL3>
XML Tag
<COUNTRYCODETO>
<LEVEL3PRODUCTS>
<MERCHANT_VAT_REGISTRATIO
N_NUM>
<ORDER_DISCOUNT_AMT>
<PURCHASER_ORDER_DATE>
Data Type /
Max Length Required
String / 3 True *
Object Array True *
String / 20 True *
Decimal / 15 True *
String / 10 True *
<PURCHASER_VAT_REGISTRATI
ON_NUM>
String / 20 True *
<SUMMARY_COMMODITY_CODE> String / 4
<VATTAX_RATE> Decimal / 15
True *
True *
<ZIPFROM> String / 20 True *
<ZIPTO>
<ALTTAX_AMT>
<ALTTAX_AMT_INDICATOR>
String / 20
Decimal / 15
String / 1
True *
False
False
<VATTAX_AMT>
<VAT_INVOICE_REFNUM>
</ LEVEL3>
Decimal / 15 False
String / 15 False
Notes Reference
Refer to Section 4.1 and 4.2 for
Methods and Section 7.1 for
Transaction Object Specification.
Country code shipped to
Array of LEVEL3PRODUCT
Merchant VAT Registration
Number
Order Discount Amount
Purchase Order Date
MMDDYYYY
Purchaser VAT Registration
Number
Summary Commodity Code
VAT Tax Rate
Zip Code Shipped From
Zip Code Shipped To
Alternate tax Amount
Alternate tax indicator, Y/N
VAT Tax Amount
VAT invoice Reference Number www.unspsc.org
*Required for Level 3 processing, if this data is not provided—transaction will still be processed, but will be downgraded to Level 2 (if all Level 2 required data is present) or to Level 1.
6.8.1
LEVEL3PRODUCT
Required if LEVEL3 object is submitted
XML Tag
<LEVEL3PRODUCT>
Data Type / Max
Length Required Notes Reference
Refer to Section 4.1 and 4.2 for Methods and
Section 7.1 for Transaction Object Specification.
<ALLTAXID> String / 12 True * Alternate tax ID number
<COMMODITYCODE> String/12
<DISCOUNTAMT> Decimal True
<DISCOUNTRATE> Decimal / 15 True * www.unspsc.org
26
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type / Max
Length
<DISCOUNT_INDICATOR> String / 10
Required Notes
True *
<GROSSNET_INDICATOR> String / 20
<ITEMCODE> String / 12
True *
True *
<ITEMNAME> String / 35 True *
<ITEMTOTALAMT> Decimal True
<QUANTITY>
<TAXAMT>
Decimal
Decimal / 15
True *
True *
<TAXTYPEIDENTIFIER> String
<TAXTYPE_APPLIED> String / 4 True *
Reference
</ LEVEL3>
*Required for Level 3 processing, if this data is not provided—transaction will still be processed, but will be downgraded to Level 2 (if all Level 2 required data is present) or to Level 1.
6.9 MPI
This object describes Merchant Plug-in Indicator for 3D Secure Transactions.
XML Tag
<MPI>
</MPI>
Data Type /
Max Length Required
<AUTHINDICATOR> String / 50
<AUTHVALUE> String / 50
False
False
Notes
The electronic commerce indicator (ECI) value for a Visa transaction; or the universal cardholder authentication field (UCAF) indicator for MasterCard transaction.
The cardholder authentication verification value (CAVV) for Visa transactions; or accountholder authentication value (AVV)/ universal cardholder authentication field
(UCAF) for MasterCard transactions.
Reference
Refer to Section 4.1 and 4.2 for
Methods and Section 7.1 for
Transaction Object Specification.
6.10 Auto
This object is used for Rental industry only and includes rental-related information, like city rented and returned in, rental and return times, etc.
<AUTO>
XML Tag
Data Type /
Max Length Required
<EXTRA_CHARGEAMOUNT> Decimal / 15 True
Notes
Additional Charge Amount
Reference
Refer to Section 4.1 and 4.2 for Methods and Section 7.1 for Transaction Object
Specification.
27
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required
<EXTRA_CHARGECODE> String / 10
<PREFERRED_CUSTOMER> String / 1
<RENTALCITY> String / 50
<RENTALDATETIME>
<RENTALSTATE>
<RETURNCITY>
String / 14
String / 2
String / 50
<RETURNDATETIME>
<RETURNSTATE>
<SALECODE>
String / 14
String / 2
String / 2
True
True
True
True
True
True
True
True
False
</AUTO>
Notes Reference
Additional Charge Code
Preferred Customer, Y/N
City Rented in
mmddyyyyhhMMss
State Rented in
City Returned In
mmddyyyyhhMMss
State Returned in
1—Sale
2—No Show
Industry defined, two-character code
6.11 Petroleum
This object is used for Petroleum industry only and includes information, like number of gallons, unit price, etc.
XML Tag
<PETROLEUM>
Data Type /
Max Length
<DRIVEJOBNUM> String / 6
<FLEET_REFERENCENUM> String / 10
<FULLSERV_INDICATOR>
<GALLONS>
<ODOMETER>
<PIN>
<PRODUCT>
String / 3
Integer / 15
String / 6
String / 10
Array of PRODUCT
Objects
<TAXAMOUNT>
<UNITPRICE>
<VEHICLENUM>
</PETROLEUM>
Decimal / 15
Decimal / 15
String / 6
False
False
False
False
False
False
True
Required
False
False
False
Notes Reference
Driver Job Number
Fleet Reference Number
Refer to Section 4.1 and 4.2 for
Methods and Section 7.1 for
Transaction Object Specification.
Full Service indicator
Number of Gallons
Odometer reading
Customer-entered PIN
Product Listing Refer to Appendix A for Petroleum
Product Codes .
Tax Amount
Price per unit
Vehicle Number
6.12 Hotel
This object is used for Hotel industry only and includes information, like check-in, check-out times, room rate, etc.
<HOTEL>
XML Tag
<CHARGETYPE>
Data Type /
Max Length Required
String / 1 True
Notes
1—Hotel /Lodging
2—Restaurant
Reference
Refer to Section 4.1 and 4.2 for
Methods and Section 7.1 for
Transaction Object Specification.
28
SecureNet Gateway Implementation Guide 4.1.5
</HOTEL>
XML Tag
<CHECKIN_DATE>
<CHECKOUT_DATE>
String / 14
String / 14
True
True
<EXTRA_CHARGEAMOUNT> Decimal / 15 True
<EXTRA_CHARGECODE> String / 10 True
<PREFERRED_CUSTOMER> String / 1
<ROOMRATE> Decimal / 15
True
True
<SALECODE> String / 2 True
Data Type /
Max Length Required Notes
3—Gift Shop
Mmddyyyy
Mmddyyyy
Additional Charge Amount
Additional Charge Code
Preferred Customer, Y/N
Rate of room
1—Sale
2—No Show
3—Deposit
4—Delayed Charge
5—Express Service
6—Assured Reservation
Reference
6.13 Product
This is optional object contains individual product information, like product description, amount, quantity, etc.
Recommended for eCommerce transactions.
XML Tag
<PRODUCT>
<UNIT>
<UNITPRICE>
</PRODUCT>
Data Type /
Max Length Required
<AMOUNT>
<CODE>
<DESCRIPTION> String / 50
<NAME> String / 30
<QUANTITY>
Decimal / 15 False
String / 9 False
String / 10
False
False
False
<TAX>
<TAXABLE>
Decimal / 15 False
String / 3 False
String / 9 False
Decimal / 15 False
Notes
Product Amount
Product Code
Product Description
Product Name
Product Quantity
Product Tax Amount
No
Yes
Unit of Measure
Price per Unit
Reference
Refer to Section 4.1 and 4.2 for Methods and Section
7.1 for Transaction Object Specification.
29
SecureNet Gateway Implementation Guide 4.1.5
6.14 Service (Restaurant)
This object is used for the Restaurant industry and contains gratuity amount and server number.
XML Tag
<SERVICE>
<GRATUITY>
<SERVERNUM>
</SERVICE>
Data Type /
Max Length Required
Decimal / 15 False
String / 6 False
Notes
Gratuity Amount
Server Number
Reference
Refer to Section 4.1 and 4.2 for Methods and Section
7.1 for Transaction Object Specification.
6.15 UserDefined
This object contains 50 user defined fields and allows merchants to store additional data along with transaction information. Please note that User Defined Fields are not intended to and must not be used to capture personally identifying information, like name, address, credit card number, social security number, driver's license number, state-issued identification number, passport number, and card verification numbers.
XML Tag
<USERDEFINED>
Data Type /
Max Length Required
<UD1>
<UD2>
String / 50
String / 50
….
<UD50>
</USERDEFINED>
String / 50
String / 50
False
False
False
False
Notes Reference
Additional Data Field
Refer to Section 4.1 and 4.2 for Methods and Section
7.1 for Transaction Object Specification.
Additional Data Field
Additional Data Field
Additional Data Field
6.16
SECONDARY_MERCHANT_KEY
This object is similar to the MERCHANT_KEY Object and is used for processing transactions across various
SecureNet IDs using information from the Vault linked to the Primary SecureNet ID.
XML Tag
<SECONDARY_MERCHANT_K
EY>
<GROUP_ID>
<SECUREKEY>
Data Type /
Max Length Required
Integer / 15 False
String / 50 True
Description Reference
This object is used to verify the merchant before processing any transaction and is required for every operation
SecureNet Group ID—Not applicable to all merchants, should be provided by
SecureNet; Please contact SecureNet for more information.
Refer to Section 4.1 and
4.2 for Methods and
Section 7.1 for Transaction
Object Specification.
Case-sensitive unique SecureKey is associated with corresponding
SecureNet ID, used to authenticate the merchant and is required for each submitted transaction.
30
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<SECURENETID>
<ADDITIONALINFO>
</SECONDARY_MERCHANT_K
EY>
Data Type /
Max Length Required
Integer / 8 True
String / 250 Required if
METHOD=E
BT
Description
7-digit unique SecureNet ID provided by
SecureNet to identify the merchant and is required for each submitted transaction
If a SecureNet ID is needed contact
SecureNet
For EBT transactions only. String format:
11 (EBT indicator) followed by a 7-digit
FNS number (left-justified, space-filled, if
FNS is less than 7 digits).
.
Reference
6.17 Terminal
This object includes merchant-related information on locations and terminal. If not provided, this information will be taken from the merchants records. If provided, this object will overwrite any existing data in the merchants records.
XML Tag
<TERMINAL>
<STORENUMBER>
<TERMINALCITY>
<TERMINALID>
Data Type /
Max Length
String / 10
String / 27
String / 20
<TERMINALLOCATION> String / 27
Required
Required for Ceridian
Required if SECCODE POS
AND several locations are being processed via one single SecureNet ID
Required if SECCODE POS
AND several locations are being processed via one single SecureNet ID
Required if SECCODE POS
AND several locations are being processed via one single SecureNet ID
Notes
Terminal City—This field identifies the city, town, village, or township in which an Electronic terminal is located
Terminal Identification Code—This filed identifies an Electronic terminal with a unique code that allows a terminal owner and/or switching network to identify the terminal at which an Entry originated
Terminal Location—This field identifies the specific location of a terminal (i.e. street names of an intersection, address, etc.) in accordance with the requirements on
Regulation E. Section 205.9(a)(5) requires that an ATM or POS terminal receipt contain the location of the terminal where the transfer is initiated, or an identification such as a code or terminal number.
Comment 9(a)(5)–1 is revised, as proposed, to clarify that either a code or location may be disclosed.
Comments 9(a) (5) (iv)–1 and –2 are re-designated as comments 9(a) (5)–
3 and –4.
Reference
Refer to Section 4.1 and 4.2 for Methods and Section 7.1 for
Transaction Object
Specification.
31
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<TERMINALSTATE>
</TERMINAL>
Data Type /
Max Length
String / 10
Required
Required if SECCODE POS
AND several locations are being processed via one single SecureNet ID
Notes
Terminal State—This field identifies state of the United States in which an
Electronic terminal is located
Reference
6.18 Healthcare
XML Tag
<HEALTHCARE>
<SERVICE_TYPECODE>
<CARRIERID>
Data Type /
Max Length Required
String / 2
String / 6
Notes
Required
Required This is the Insurance company Id
(Provider Id)
Reference
Refer to Section 4.1 and 4.2 for
Methods and Section 7.1 for
Transaction Object Specification.
Appendix A, Section G for URL
<PRESCRIPTION_AMOUNT> decimal
<DENTAL_AMOUNT> decimal Amount
</HEALTHCARE>
6.19 Image
XML Tag
<IMAGE>
<SIGNATURE > Byte Array
<CHECK IMAGE> Object/1
</IMAGE>
Data Type /
Max Length Required
Required for Signature update
Required for Check21 transactions for check image capturing
Notes Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for Transaction Object Specification.
Refer to the CHECKIMAGE Object
6.19.1
Checkimage
XML Tag
<CHECKIMAGE>
Data Type /
Max Length Required
<FRONTSIDE>
</CHECKIMAGE>
Byte Array Required
Notes Reference
Refer to Section 4.1 and 4.2 for methods and section 7.1 for Transaction Object Specification.
32
SecureNet Gateway Implementation Guide 4.1.5
6.20 Transaction Vault Object Summary
This object defines information that can be submitted to the Gateway for Vault transaction processing.
TRANSACTION_VAULT
6.20.1
Transaction Vault Object Specification
ACCOUNT_VAULT
CUSTOMER_VAULT
MERCHANT_KEY
OPERATIONPARAMETERS
TRANSACTION
6.20.1.1 TRANSACTION_VAULT
This object defines information that can be submitted to the Gateway for Vault transactions processing.
XML Tag
<TRANSACTION_VAULT>
Data Type /
Max Length Required Methods Used
Methods using this object include:
ProcessAccount
ProcessCustomer
ProcessVaultTransaction
ProcessCustomerAndAccou nt
< ACCOUNT_VAULT >
< CUSTOMER_VAULT >
< MERCHANT_KEY >
< OPERATIONPARAMETER
S >
Object / 1
< TRANSACTION >
</TRANSACTION_VAULT>
Object / 1
Object / 1
Object / 1
Object / 1
True
True
True
True
True
Reference
Refer to Section 4.1 and 4.2 for methods and section 8.2 for Vault
Object Specification.
Refer to the ACCOUNT_VAULT
Object
Refer to the CUSTOMER_VAULT
Refer to the MERCHANT_KEY
Object
Refer to the
OPERATIONPARAMETERS
Object
Refer to the TRANSACTION
Object
33
SecureNet Gateway Implementation Guide 4.1.5
6.20.2
ACCOUNT_VAULT
This object contains account information to add, update or delete, like payment method and corresponding card/account information.
XML Tag
Data Type /
Max Length Required Methods Used
Methods using this object include:
ProcessAccount
ProcessCustomer
ProcessVaultTransaction
ProcessCustomerAndAccount
CopyVaultAccount
Reference
<ACCOUNT_VAULT>
<
<
<
ACDI >
CARD >
CHECK >
<CUSTOMERID>
Integer / 1 False
OBJECT / 1 Required if
METHOD = CC,
PD
Account Duplicate Indicator. Values:
0, 1, 2, 3. Refer to ACDI in Appendix
A for more information.
OBJECT / 1 Required if
METHOD =
ECHECK
String / 25 True
Contains the customer ID associated with the transaction or record.
This can be generated using any string or system created using
“AUTO”. If AUTO is specified, a unique CUSTOMERID is generated and returned in the response object.
It cannot be a valid card number.
< CUSTOMER_BILL > OBJECT / 1 Required for E-
Commerce transactions
<METHOD> String / 7 True
<NOTES> String / 250 False
Indicates method of payment for the transaction being sent to the system.
Additional Notes field.
Refer to Section 4.1 and 4.2 for
Methods and Section 8.2 for Vault
Object Specification.
Refer to the CARD Object
Refer to the CHECK Object
It is recommended to use the specific customer ID versus AUTO.
If you choose to have the ID automatically generated, note that
AUTO is case sensitive.
Refer to Appendix A for more information.
<PAYMENTID> String / 25 True Contains the Payment ID associated with the customer record.
This can be generated using any string or system created using
“AUTO”. If AUTO is specified, a unique PAYMENTID is generated and returned in the response object.
It cannot be a valid card number.
It is recommended to use the specific payment id versus AUTO.
If you choose to have the ID automatically generated, note that
AUTO is case sensitive.
34
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<PRIMARY>
Data Type /
Max Length Required
String / 5 False
< USERDEFINED > OBJECT / 1 False
<CARDTYPE> STRING
<LASTACCESSDATE> STRING
</ACCOUNT_VAULT>
Methods Used Reference
Specifies if the account is Primary or not.
Values: TRUE or FALSE; Set to FALSE by default.
Multiple accounts (payment methods) can be stored for a single customer and only one account can be set as primary.
The system will automatically default to another payment method for the customer if the primary payment is declined.
Upper case values only
Refer to the USERDEFINED Object
Returned in the response
Returned in the response
6.20.3
CUSTOMER_VAULT
This object contains customer information to add, update or delete, like customer name, address, email, phone number, etc.
XML Tag
<CUSTOMER_VAULT>
Data Type /
Max Length Required
<CSDI>
<CUSTOMERID>
< CUSTOMER_BILL >
<NOTES>
< USERDEFINED >
Integer / 1
String / 25
Object / 1
String / 200
Object / 1
True
True
False
False
False
Notes Reference XML Tag
Refer to Section 4.1 and 4.2 for Methods and Section 8.2 for
Vault Object
Specification
<CUSTOMER_VAULT
>
<CSDI> Customer Duplicate Check
Indicator
0 - If Customer ID exists then return an Error.
1 - If Customer ID exists then do not add account but continue with transaction.
Contains the customer ID associated with the transaction or record.
Can be any string or AUTO.
If AUTO is specified a unique
CUSTOMERID is generated and returned in the response object. It cannot be a valid card number.
Object containing Billing
Customer information.
Additional Notes field.
Object Containing 50 user defined fields.
<CUSTOMERID>
Recommended to use specific customer id than AUTO.
AUTO is case sensitive
< CUSTOMER_BILL >
<NOTES>
< USERDEFINED >
35
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
</CUSTOMER_VAULT>
Data Type /
Max Length Required Notes Reference XML Tag
</CUSTOMER_VAULT
>
6.20.4
OPERATIONPARAMETERS
This object is used to specify operation type (Add, Update, or Delete) and to specify whether Vault information is to be added even when transaction is declined in ProcessVaultTransaction method.
XML Tag
<OPERATIONPARAMETERS>
Data Type /
Max Length Required
<ACTIONCODE>
<ADD_IF_DECLINED>
</OPERATIONPARAMETERS>
Integer / 1
Integer / 1
False
False
Notes
1—ADD
2—Update
3—Delete
Add Customer/Account if transaction is declined:
0—False
1—True
Reference
Refer to Section 4.1 and 4.2 for
Methods and Section 8.2 for Vault
Object Specification.
If not included, the default will be to
ADD the transaction data to the Vault.
6.21 AutoBill Transactions
The AutoBill feature allows merchants to set up automatic scheduled and recurring credit card and ACH transactions. Using the “Recurring AutoBill” payments can be scheduled for daily, weekly, monthly, quarterly, and yearly recurrence. Merchants can use the “Variable AutoBill” to set up one or more future-dated payments. Lastly, the “Installment AutoBill” will take a total amount due and split the payment amount evenly across the designated time period with flexible variability on the recurrence schedule (i.e. weekly, monthly, etc.).
6.21.1
PLAN_AB Object Specification
6.21.1.1 PLAN_AB
This object defines the information that can be submitted to the Gateway for AutoBill transaction processing.
XML Tag
<PLAN_AB>
Data Type /
Max Length Required Methods Used
This object can be used with the following methods:
AddABAAccount
UpdateABAccount
UpdateABSchedule
Reference
Available through:
36
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required Methods Used Reference
<CUSTOMERID>
<ENDDATE>
< >
<MAXRETRIES>
< >
String / 25
String / 8
Object / 1
Integer / 1
Object / 1
<NEXTPAYMENT_DATE> String / 8
<PAYMENTID>
<PAYMENTID2>
<
INSTALLMENT
MERCHANT_KEY
RECURRING
<SCHEDULE>
>
<STARTDATE>
String / 25
String / 25
Object / 1
Array of
PAYMENT_AB
String / 8
Available in response. Shows whether recurring billing on this record is enabled or disabled.
0—Inactive
1—Active
True Contains customer ID associated with payment plan. It cannot be a valid card number.
Required if
NOEND_FLAG = 0
(recurring bill has an end date)
True
Plan end date. MMDDYYYY.
False
True
Refer to PLAN_AB
Object Summary
AutoBill offers the ability to reattempt a declined transaction every day for up to five consecutive days.
Enter maximum number of retries, default is
0, maximum is 5.
This object is used to verify merchant before processing any transaction and is required for any operation.
Refer to
MERCHANT_KEY
Object
False
True
False
Update only
True
Available in response.
Next payment date. MMDDYYYY.
SecureNet Vault Payment ID.
Must be enabled on the account.
It cannot be a valid card number.
Process through Payment ID 2 if there is a problem with Payment ID.
Payment plan ID, auto-generated by the system and given to the merchant at the time
Plan is added.
True
True
Refer to
RECURRING Object
Refer to
PAYMENT_AB
Object
<TYPE>
</PLAN_AB>
String / 3 True
Plan start date. MMDDYYYY.
Verify the date is on or after current date.
Billing types offered include Recurring
Billing, Installment Billing and Variable
Billing.
Set TYPE to one of the following:
REC—for recurring
INS—for installment
VAR—for variable
37
SecureNet Gateway Implementation Guide 4.1.5
6.21.1.2 PLAN_AB_EXT
XML Tag
<PLAN_AB_EXT>
<PLAN_AB>
Data Type /
Max Length Required
PLAN_AB True Base class object
<USERDEFINED> USERDEFIN
ED
</PLAN_AB_EXT>
False
Notes
Contains the User Defined Values for the corresponding
PLAN_AB object
Reference
6.21.1.3 OPTIONS
Please note that OPTIONS is a parent class of INSTALLMENT and RECURRING, so all parameters of OPTIONS are inherited by the two subclasses and are included in INSTALLMENT and RECURRING tables below.
XML Tag
<OPTIONS>
<CYCLE>
<DAY>
</OPTIONS>
Data Type /
Max Length
String / 1
Integer / 2
<FREQUENCY> Integer / 2
<MONTH>
<WEEKDAY>
Integer / 2
Integer / 1
True
Required Notes
Required if
CYCLE=M, Q, B, or Y
True
W—weekly
M—monthly
Q—quarterly
B—semiannual
Y—yearly
1 – 28
Once every period as following:
If CYCLE=M: 1 – 11 (i.e. 2 = every 2 months) if CYCLE=W: 1 – 51 (i.e. 6 = every 6 weeks) for CYCLE=Y, B and Q - frequency is set automatically
1-12 Required if
CYCLE=Q, B, or Y
Required if
CYCLE=W
1-7, where 1 is Sunday
Reference
6.21.1.4 INSTALLMENT
Installment payment plans consist of a single purchase of goods or services that is billed to an account in multiple segments, over a period of time, with payments occurring on a schedule agreed by a cardholder and merchant. The INSTALLMENT object below contains information on the Customers Installment plan.
XML Tag
<INSTALLMENT>
Data Type /
Max Length Required Notes Reference
38
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required Notes
<CYCLE> String / 1 True W—weekly
M—monthly
Q—quarterly
B—semiannual
Y—yearly
1-28 <DAY> Integer / 2 Required if CYCLE=M,
Q, B, or Y
True <FREQUENCY>
</INSTALLMENT>
Integer / 2
<REMAINDER_OPTION> Integer / 1 True
Once every period as following:
If CYCLE=M: 1 – 11 (i.e. 2 = every 2 months) if CYCLE=W: 1 – 51 (i.e. 6 = every 6 weeks) for CYCLE=Y, B and Q - frequency is set automatically
1 – 12 <MONTH> Integer / 2 Required if CYCLE=Q,
B, or Y
<WEEKDAY>
<AMOUNT>
Integer / 1
Decimal / 15 True
<AUTOCALC_OPTION> String / 1
Required if CYCLE=W 1 - 7, where 1 is Sunday
True
Installment amount
<BALLOON_AMOUNT> Decimal / 15
<BALLOON_OPTION> Integer / 1
True
True
A—automatic
M—manual
Balloon amount
AutoBill offers the capability of the balloon payment to be applied to the first or last payment, as following:
0 - add balloon amount to first payment
1 - add balloon amount to last payment
<COUNT> Integer / 2 True Number of total installments for installment plan.
1-99.
AutoBill offers the ability to choose first or last payment if installments are not equally divided, as following:
0 - add remainder to first payment
1 - add remainder to last payment
Reference
6.21.1.5 RECURRING
Recurring payment plans exist when multiple transactions are processed at pre-determined intervals, as a result of an agreement for the purchase of products or services that are provided over time. Recurring payment plans help simplify the process of billing a cardholder for a product or a service that is being provided on a continuous basis.
XML Tag
Data Type /
Max Length
<RECURRING>
<CYCLE> String / 1 True
Required
W—weekly
M—monthly
Q—quarterly
B—semiannual
Y—yearly
Notes Reference
39
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required Notes
<DAY> Integer / 2 Required if CYCLE=M,
Q, B, or Y
True
1-28
<FREQUENCY> Integer / 2
</RECURRING>
Once every period as following:
If CYCLE=M: 1 – 11 (i.e. 2 = every 2 months) if CYCLE=W: 1 – 51 (i.e. 6 = every 6 weeks) for CYCLE=Y, B and Q - frequency is set automatically
1 – 12 <MONTH>
<WEEKDAY>
<AMOUNT>
Integer / 2 Required if CYCLE=Q,
B, or Y
Integer / 1 Required if CYCLE=W 1 - 7, where 1 is Sunday
Decimal / 15 True Total value to be charged to the payment method specified.
Include decimal point followed by decimal amount.
<NOEND_FLAG> Integer / 1 True 0 = Recurring bill has an end date
1 = Recurring bill has no end date
Reference
6.21.1.6 PAYMENT_AB
This object contains individual payment information, like amount, payment id, installment date, etc.
XML Tag
<PAYMENT_AB>
<AMOUNT>
Data Type /
Max Length Required
Decimal / 15 True
<INSTALLMENTDATE> String / 8
<INSTALLMENTNUM> Integer / 2
<NUMOFRETRIES> Integer / 1
<PAID>
<PAYMENTDATE>
<PAYMENTID>
Integer
String
String / 25
True
True
True
False
False
True
Required for
Update only
<PROCESSED> Integer / 1 False
Notes
Total amount to be charged to the payment method specified.
Include decimal point followed by decimal amount.
Installment date. MMDDYYYY.
Installment number of “this” payment
AutoBill offers the ability to reattempt a declined transaction every day for up to five consecutive days.
Enter number of retries, between 1 - 5.
Available in response.
0 = installment has not yet been paid
1 = installment has been paid
Available in response.
Will contain payment date of that Schedule ID for
Installment and Variable billing, for Recurring billing— represents next billing date.
Contains the Payment ID associated with the customer record.
Can be any string or AUTO.
If AUTO is specified, a unique PAYMENTID is generated and returned in the response object.
Payment plan ID, auto-generated by the system and given to the merchant at the time Plan is added.
0—not yet processed, still in the queue
1—processed
Reference
40
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required
<SCHEDULEID> Integer Required for
Update only
<TRANSACTIONID>
</PAYMENT_AB>
Integer / 15 False
Notes
AutoBill allows multiple billing schedules per Customer ID.
Schedule ID, auto-generated by the system and given to the merchant at the time Schedule is added.
Available in response; System Generated Unique ID for corresponding transaction, returned by the Gateway.
Reference
6.22 Settlement Transactions
In order to close a batch the below object is required.
Object Name
MERCHANT_KEY
Description
Required for CloseBatch method.
Reference
41
SecureNet Gateway Implementation Guide 4.1.5
7 Reporting API Services
The Reporting API services allow merchants to perform additional functions within their processing systems by collecting and reporting on transactional data within the SecureNet Gateway. The following services are available through the Reporting API:
NOTE: Data in the reporting services database is not updated in real-time, there is a 30-minute delay.
Transactions Services:
Retrieve
Retrieve Current Transaction Info by Order ID
Retrieve Current Transaction Info by Transaction ID
Vault Services:
Allow to lookup Customer and Account information
AutoBill Services:
Allow to lookup AutoBill Account information
Batch Services:
Allow the system to initiate a batch close on demand
P2P Encryption Services:
Request a new P2P Encryption Key
Confirm a new P2P Encryption Key
Retrieve the current Active Primary or Active Secondary P2P Encryption Key
To implement any of the above functions, create a program to consume one of the following Gateway Services:
For Batch and Transaction Services:
URL for Production: https://gateway.securenet.com/api/data/transaction.svc
URL for Certification and Test: https://certify.securenet.com/api/data/transaction.svc
For SecureNet Vault and AutoBill Services:
URL for Production: https://gateway.securenet.com/api/data/service.svc
URL for Certification and Test: https://certify.securenet.com/api/data/service.svc
For P2P Encryption Services:
URL for Production: https://gateway.securenet.com/api/data/service.svc
URL for Certification and Test: https://certify.securenet.com/api/data/service.svc
Request Objects used for the Reporting API are as follows:
Object Name
MERCHANT_KEY
P2PRequest
P2PConfirmationRequest
Description
Required for all Reporting API methods .
Required for requesting a new P2P Encryption Key
Required for Confirmation and Activation of a new P2P Key.
Reference
This section outlines the various sections within the P2PRequest object.
P2PREQUEST
MERCHANT_KEY
P2PREQUEST
This object defines the fields required for requesting and confirming a new P2P Encryption Key.
MERCHANT_KEY
A MERCHANT_KEY representing the current client.
42
SecureNet Gateway Implementation Guide 4.1.5
7.1.1
P2PREQUEST Object Specification
This object defines information that can be submitted to the P2P Encryption service for processing when requesting a new P2P Encryption Key.
XML Tag
Data Type /
Max Length Required
<P2PREQUEST>
< MERCHANT_KEY > Object / 1
</P2PREQUEST>
True
Notes
7.1.2
P2PConfirmationRequest Object Structure
This section outlines the various sections within the P2PConfirmationRequest Object.
P2PConfrimationReques t
ENCRYPTED_STRING
KEYID
MERCHANT_KEY
Reference
7.1.3
P2PConfirmationRequest Object Specification
This object defines information that can be submitted to the P2P Encryption service for processing when confirming and activating a new P2P Key.
XML Tag
Data Type /
Max Length Required Notes
<P2PConfirmationRequest
>
<ENCRYPTED_STRING> String/172 True
<KEYID> Integer True
Gets or sets the encrypted string used during confirmation of the P2P Key.
Gets or sets the ID of the P2P Key.
< MERCHANT_KEY > Object True Gets or sets the requesting client's
MERCHANT_KEY . (Inherited from P2PRequest .)
</P2PConfirmationRequest>
Reference
Available through:
Extended Services
Extended Services
7.1.4
P2PPublicKeyInfo
This object defines the P2P Encryption Public Key information that is part of the response.
XML Tag
<P2PPublicKeyInfo>
<Exponent>
Data Type /
Max Length
String / 4
Notes Reference
Available through:
The Exponent variable used for calculating the encryption key. Extended Services
43
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length
<Modulus>
</ P2PPublicKeyInfo >
String / 172
Notes Reference
The Modulus variable used for calculating the encryption key. Extended Services
7.2 Reporting Methods for Batch and Transaction Services Input Parameters
Object Name
MERCHANT_KEY SECURENETID
SECUREKEY
BatchID
TransactionID
OrderID
StartDate
EndDate
ExcludeDate
Amount
Description
Should be a valid Batch id
Should be valid TransactionID
Should be valid OrderID
MM/DD/YYYY
MM/DD/YYYY must be greater or equal to the
StartDate.
The difference between the StartDate and EndDate should not be more than 30 days
ExcludeDate value 1 or 0, if 1 start date and enddate are overridden and the transactions would be searched within the last 180 days
Amount should contain valud value or zero to be ignored
Methods used
All Methods
GetBatchTransactions
GetTransactionByTransactionID Transaction Services
GetTransactionByOrderID
GetTransactions
GetTransactions
GetTransactions
GetTransactions
Reference
Transaction Services
Extended Services
Gateway Services
Transaction Services
Transaction Services
Transaction Services
Transaction Services
Transaction Services
Transaction Services
Customer ID Customer ID should contain a valid value otherwise it should be an empty string.
Reserved
GetTransactions
Reserved
Transaction Services
Reserved RBOnly
44
SecureNet Gateway Implementation Guide 4.1.5
8 TRANSACTION REQUEST MESSAGE FORMAT
All Gateway transactions include a common set of required parameters (listed first). Additional parameters are required depending on the transaction type. Many optional parameters can also be provided depending on the results that are to be returned.
8.1 Format for Credit Card, Debit Card, EBT, and Stored Value Card Transactions
XML Tag
<TRANSACTION>
Data Type /
Max Length
Object / 1 True
Required Sample Values Reference
<AMOUNT>
<
<CODE>
<METHOD>
< CARD >
<OrderID>
<DCI>
<TEST>
<
MERCHANT_KEY
REF_TRANSID >
>
<TRANSACTION_SER
VICE>
Decimal / 15
Object / 1
String / 4
String / 7
Object / 1
String / 25
Integer / 1
String / 5
Integer / 1
String / 15
True
True
True
True
True
True
True
True
True
Required for
Transaction Code
Total amount to be charged or credited.
Include decimal point followed by decimal amount
Gateway Services
SECURENET ID
SECUREKEY
Refer to
MERCHANT_KEY object for additional values
Refer to the Transaction
Type Table for additional values
0000—AUTH_ONLY
0100—AUTH_CAPTURE
0200—PRIOR_AUTH_CAPTURE
0201—UPDATE_TRANS_INFO
0300—CAPTURE_ONLY
0400—VOID
0401—PARTIAL_VOID
0402—VOID_BY_OrderID
0500—CREDIT
0600—FORCE_CREDIT
0700—VERIFICATION
CC, DB, SV, EBT
Unique Transaction Order ID.
Alphanumeric (Valid values String A-Z, 0-
9)
0, 1, 2, 3
Refer to METHOD for additional values
Refer to the Card Object
Refer to OrderID in
Appendix A
Refer to DCI in Appendix
A
This is case sensitive values
TRUE = Test Transaction
FALSE = Live Transaction
Default is FALSE
Indicates Transaction Handling when
Vault is enabled. Values are 0,1,2,3 – default is 0.
Transaction ID of a previously approved transaction, used in Transaction Code
0400—VOID
0401—PARTIAL_VOID
0500—CREDIT
0200—PRIOR_AUTH_CAPTURE
Refer to
TRANSACTION_SERVIC
E in Appendix A
Refer to REF_TRANSID in
Appendix A for more details
Transaction id value should be a number
45
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<INDUSTRYSPECIFIC
DATA>
<INSTALLMENT_SEQ
UENCENUM>
<TOTAL_INSTALLMEN
TCOUNT>
<AUTHCODE>
<CUSTOMERID>
<PAYMENTID>
< AUTO >
< PETROLEUM >
Data Type /
Max Length
String / 1
Integer / 2
Integer / 2
String / 6
String / 25
String / 25
Object / 1
Object / 1
Required Sample Values
Required for eCommerce and
MOTO transactions
Leave blank for
Retail transactions
Required if
INDUSTRYSPECIF
ICDATA=3
Required if
INDUSTRYSPECIF
ICDATA = 3
Required for 300 transactions
Industry Specific Data—Required to send the right indicator for transaction.
Accepted values:
P and D - eCommerce
1, 2, and 3 - MOTO
Installment number for installment payment plan 1 – 99
Number of total installments for installment plans 1 – 99
Required for Vault transactions
Required for Vault transactions
Specific to Industry
Specific to Industry
Valid authorization code for Offline
Transaction 0300—CAPTURE_ONLY
Voice Authorization Code
Valid authorization code for EBT Voucher transaction 0300—CAPTURE_ONLY
Contains the customer ID associated with the Authorization Code for EBT Voucher transaction
Must be enabled on the account
SecureNet Vault Payment ID
Must be enabled on the account
Reference
Refer to
INDUSTRYSPECIFICDAT
A in Appendix A for more information.
No space and special character
No space and special character
Refer to the AUTO Object.
Refer to the PETROLEUM
Object.
< HOTEL >
< SERVICE >
<CUSTOMERIP>
Object / 1
Object / 1
String / 15 False
<DEVICECODE>
<ENTRYSOURCE>
<INVOICEDESC>
<INVOICENUM>
String / 2
String / 10
String / 50
String / 50
False
False
False
Required for
Ceridian
The Customer IP address includes the
Customers IP that needs to be associated with the transaction
Recommended for ecommerce merchants
Valid IP of customer
Code for payment device
Blank, unless specified/ provided by
SecureNet
Transaction Source
Blank, unless specified/provided by
SecureNet
Description of the transaction for which invoice is being issued
Invoice number associated with the transaction
46
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<MARKETSPECIFICDA
TA>
Data Type /
Max Length
String / 2
Required
False
<NOTE> String / 500 False
<OVERRIDE_FROM> Integer / 1 False
<RETAIL_LANENUM> String / 6
<SOFTDESCRIPTOR> String / 25
False
False
< CUSTOMER_BILL > Object / 1
< CUSTOMER_SHIP > Object / 1
< ENCRYPTION >
< LEVEL2 >
< LEVEL3 >
Object / 1
Object / 1
Object / 1
False
False
False
False
False
Sample Values Reference
For bill payment transactions, applicable for Visa only
B—Bill payment
D—Debt indicator (contact SecureNet for more info)
Don't include if a value isn’t sent
For Nashville processor all VISA
Recurring and VISA Installment transactions are considered as Bill
Payment transactions by default
VISA Single Bill payment MOTO transactions are also considered as Bill
Payment
Additional Transaction Notes
Transaction information, billing information and UDF data will come from the listed sources based on the value of this flag:
0 - Transaction Request
1 - Customer Vault Object
2 - Account Vault Object
3 - 0200—PRIOR_AUTH_CAPTURE transaction request, Level 2 information will be overwritten with the new Level 2 values. This should also be used for
0200—PRIOR_AUTH_CAPTURE and
SecureNet Vault transactions.
4 – Customer Vault Billing Information and
Transaction UDF
5 – Account Vault Billing Information and
Transaction UDF
6 - Transaction Billing Information
Customer Vault UDF
7 - Transaction Billing Information and
AccountVault UDF
8 – Account Vault Billing Information and
Customer Vault UDF
9 – Customer Vault Billing Information and
Account Vault UDF
Lane Number for Retail stores
Additional DBA descriptor Refer to
SOFTDESCRIPTOR in the Appendix.
Refer to
CUSTOMER_BILL Object.
Refer to
CUSTOMER_SHIP Object
Refer to ENCRYPTION
Object
47
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Required Sample Values Reference
<
<
PRODUCT
USERDEFINED > Object / 1
False
False
Refer to PRODUCT
Object
Refer to USERDEFINED
Object
< MPI > Object / 1 False
< SECONDARY_MERCH
ANT_KEY >
Object / 1 False Refer to
SECONDARY_MERCHA
NT_KEY Object
< TERMINAL > Object/1 Terminal Object
<DEVELOPERID> String/8 True
<VERSION> String
< IMAGE >
</TRANSACTION>
Object /1 False
Assigned by SecureNet
Application version of the client performing the transaction. Assigned by
SecureNet
Refer to the
HEALTHCARE Object
Refer to the IMAGE
Object
8.2 Format for Electronic Check Transactions
XML Tag
<TRANSACTION>
<AMOUNT>
< MERCHANT_KEY >
<CODE>
<METHOD>
< CHECK >
Data Type /
Max Length Required
Object / 1 True
Decimal / 15 True
Object / 1
String / 4
String / 7
Object / 1
True
True
True
True
Sample Values
Total amount to be charged or credited.
Include decimal point followed by decimal amount
SECURENETID
SECUREKEY
Reference
Refer to the transaction object
Indicates the type of processing required for
Transaction Request.
0000—AUTH_ONLY
0100—AUTH_CAPTURE
0200—PRIOR_AUTH_CAPTURE
0201—UPDATE_TRANS_INFO
0300—CAPTURE_ONLY
0400—VOID
0401—PARTIAL_VOID
0402—VOID_BY_OrderID
0500—CREDIT
0600—FORCE_CREDIT
0700—VERIFICATION
Set Transaction Method to ECHECK
Refer to the
MERCHANT_KEY object for additional values
Refer to the Transaction Type
Table for additional values
Refer to the METHOD for additional values in the
Appendix.
Refer to the Check Object
48
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<OrderID>
<DCI>
<TEST>
<REF_TRANSID>
<PAYMENTID>
<CUSTOMERID>
<CUSTOMERIP>
<ENTRYSOURCE>
<INVOICEDESC>
<INVOICENUM>
<NOTE>
Data Type /
Max Length Required
String / 25 True
Integer / 1
String / 5
<TRANSACTION_SER
VICE>
Integer / 1
String / 15
String / 25
String / 25
String / 15
String / 2
String / 50
String / 50
True
True
True
Required for
0200,0201
Required for
Vault transactions
Required for
Vault transactions
False
False
False
False
String / 500 False
Sample Values
Unique Transaction Order ID Alphanumeric
(Valid values String A-Z, 0-9)
Duplicate Check Indicator
Sample values: 0,1,2,3
TRUE = Test Transaction
FALSE = Live Transaction
Default is FALSE.
Indicates Transaction Handling when Vault is enabled
Valid values: 0,1,2,3; Default = 0
Transaction ID of a previously approved transaction, used in transaction codes
SecureNet Vault Payment ID
Alphanumeric (Valid values String A-Z, 0-9)
Or “AUTO” (SecureNet API would generate a unique numeric value for reference)
Contains the customer ID associated with the transaction
Alphanumeric (Valid values String A-Z, 0-9)
Or “AUTO” (SecureNet API would generate a unique numeric value for reference)
Customer IP address
Include the Customers IP that needs to be associated with the transaction
Recommended for e-Commerce transactions. The IP of the customer should be captured and can be submitted to be associated with the transaction.
Transaction Source
Blank, unless specified/provided by
SecureNet
Description of the transaction for which invoice is being issued
Invoice number associated with the transaction
Additional Transaction Notes
Reference
Refer to the OrderID in
Appendix A for additional information.
Refer to the DCI in Appendix
A for additional information
Case sensitive value
Refer to the
TRANSACTION_SERVICE in Appendix A for additional information
Refer to Appendix A for more uses of REF_TRANSID
It should have number value
Alpha number value, no space and no special characters
Alpha number value, no space and no special characters
49
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<OVERRIDE_FROM> Integer / 1
<RETAIL_LANENUM> String / 6
<SOFTDESCRIPTOR> String / 25
< CUSTOMER_BILL > Object / 1
< CUSTOMER_SHIP > Object / 1
< ENCRYPTION >
< USERDEFINED >
< MPI >
< SECONDARY_MERC
HANT_KEY >
<IMAGE>
</TRANSACTION>
Data Type /
Max Length
Object / 1
Object / 1
Object / 1
Object / 1
Object/ 1
Required
False
False
False
False
False
False
False
False
False
False
<DEVELOPERID> String/8 False
<VERSION> String/10
Sample Values
Transaction information—Billing information and UDF data—will come from the below sources based on the value of this flag:
0 - Transaction Request
1 - Customer Vault Object
2 - Account Vault Object
3 - 0200—PRIOR_AUTH_CAPTURE transaction request, Level 2 information will be overwritten with the new Level 2 values.
This should also be used for 0200—
PRIOR_AUTH_CAPTURE and SecureNet
Vault transactions.
4 - CustomerVault Billing Information and
Transaction UDF
5 - AccountVault Billing Information and
Transaction UDF
6 - Transaction Billing Information
CustomerVault UDF
7 - Transaction Billing Information and
AccountVault UDF
8 - AccountVault BillingInformation and
CustomerVault UDF
9 - CustomerVault Billing Information and
AccountVault UDF
Lane Number for Retail stores
Additional DBA descriptor
Reference
Refer to the
SOFTDESCRIPTOR in the
Appendix
Refer to the
CUSTOMER_BILL Object
Refer to the
CUSTOMER_SHIP Object
Refer to the ENCRYPTION
Object
Refer to the USERDEFINED
Object
Refer to the MPI Object
Refer to the
SECONDARY_MERCHANT_
KEY
Assigned by SecureNet
Application version of the client performing the transaction
Assigned by SecureNet
Refer to the IMAGE Object
50
SecureNet Gateway Implementation Guide 4.1.5
8.3 Transaction Image Request
All Gateway transactions include a common set of required parameters (listed first). Additional parameters are required depending on the transaction type. Many optional parameters can also be provided depending on the results that are to be returned.
8.3.1
Transaction Image Request Message Format for Electronic Signature
XML Tag
<IMAGETYPE>
<MERCHANT_KEY>
<SIGNATURE>
<CHECKIMAGE>
<TransactionID>
Data Type /
Max Length Required
Object / 1 True
Sample Values
ECHECK, SIGNATURE
Object / 1
Byte array
Object/ 1
True
True
False
SECURENET ID
SECUREKEY
Signature in byte array
Not required
Integer / 15 True System Generated Unique ID for corresponding transaction, returned by the
Gateway
True Contains response code, sub code and reason text
Reference
Available Through:
Gateway Services
Refer to MERCHANT_KEY object for additional values
<TransactionID>
51
SecureNet Gateway Implementation Guide 4.1.5
9 RESPONSES
This section describes the responses returned by the Gateway when a merchant server submits a transaction for processing. These responses are objects that contain properties and response values showing the status of a transaction. The merchant server retrieves this data and determines the message to display to the end-user.
9.1 Standard Transaction Responses Structure
This section describes the response returned by the Gateway when a merchant server submits a transaction for processing.
GATEWAYRESPONSE
ABRESPONSE
SCHEDULE
TRANSACTIONRESPONSE
CUSTOMER_BILL
VAULTACCOUNTRESPONSE
VAULTCUSTOMERRESPONSE
P2PKEYRESPONSE
9.1.1
GATEWAYRESPONSE Object Specification
Property Name
ABRESPONSE
Type Description
Object Response for AutoBill Transactions
Can be part of GATEWAYRESPONSE or standalone for transactional responses
Constraints
All restrictions as defined in the Request
Object Specs apply.
All restrictions as defined in the Request
Object Specs apply.
Transactions and Reporting API
Transactions
Can be part of GATEWAYRESPONSE or standalone for transactional responses
Response for SecureNet Vault Account
Transactions
Can be part of GATEWAYRESPONSE or
Standalone for transactional responses
VAULTCUSTOMERRESPONSE Object Response for SecureNet Vault Customer
Transactions
Can be part of GATEWAYRESPONSE or standalone for transactional responses
P2PKEYRESPONSE Object Contains the results of the P2P Encryption request
Can be part of GATEWAYRESPONSE or standalone for transactional responses
All restrictions as defined in the Request
Object Specs apply.
All restrictions as defined in the Request
Object Specs apply.
All restrictions as defined in the Request
Object Specs apply.
Reference
Gateway
Services
Gateway
Services
Transaction
Services
Gateway
Services
Gateway
Services
Extended
Services
Transaction
Services
52
SecureNet Gateway Implementation Guide 4.1.5
9.1.1.1 ABRESPONSE
This object defines the information that will be sent by the Gateway as a response for AutoBill transactions.
NOTE: All fields in the ABRESPONSE object are returned in a left-justified, space-filled format.
XML Tag
<ABRESPONSE>
<RESPONSE_CODE>
Data Type /
Max Length
String / 10
Notes
Transaction Response Code.
<RESPONSE_REASON_CODE>
<RESPONSE_REASON_TEXT>
<RESPONSE_SUBCODE>
<CUSTOMERID>
<PAYMENTID>
String / 10
String / 200
String / 10
String / 25
String / 25
Code for providing more details about the result of the transaction.
Brief description of the result, which corresponds with the Response Reason Code.
Code used by the system for internal transaction tracking.
Contains the customer ID associated with the transaction or record.
Contains the Payment ID associated with the customer record.
<PLANID> Integer
<SCHEDULE> Object / 1 Echoed from PLAN_AB
</ABRESPONSE>
Reference
Available through:
Refer to response codes in the Appendix.
9.1.1.2 TRANSACTIONRESPONSE
This object defines the information that will be sent by the Gateway as a response for all standard payment transactions, as well as transactions submitted through Reporting API Services.
NOTE: All fields in the TRANSACTIONRESPONSE object are returned in a left-justified, space-filled format.
XML Tag
<TRANSACTIONRESPONSE>
<ADDITIONALAMOUNT>
Data Type /
Max Length Notes
Decimal / 15 For Debit cards it will contain the surcharge for the transaction, if one has been setup on the Host. (If surcharge applies, it must be printed on the customer receipt). Applicable to Paymentech only.
For EBT and Stored Value cards it will contain the remaining balance on the card.
See Appendix for Additional Data Chart .
Reference
Available through:
Gateway
Services
53
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Notes
<ADDITIONALDATA1>
<ADDITIONALDATA2>
String / 100 For Stored Value cards. Includes Previous Balance (15 characters long zero filled decimal number with explicit decimal point) followed by Cash Out Amount (15 characters long zero filled decimal number with explicit decimal point).
See Appendix for Additional Data Chart .
String / 100 Paymentech specific data -for Debit Transactions it will contain the
Trace Number for the transaction. Optional data returned by the
Host for Fleet Cards. (If data exists, it must be printed on the customer receipt as reference data). For PD transactions, settlement date is returned.
For EBT transactions it will contain the FNS # echoed from the
ADDITIONALINFO field of the MERCHANT_KEY object.
See Appendix Additional Data Chart .
<ADDITIONALDATA3>
<ADDITIONALDATA4>
<ADDITIONALDATA5>
String / 100 For EBT transactions it will contain the Voucher # echoed from the
ADDITIONALINFO field of the CARD object.
See Appendix for Additional Data Chart .
String / 100 for ISSUE_VIRTUAL: Virtual issued card Pin Number
String / 100 P2P Encryption Transaction Response in the format:
MMddyyyyHHmmss
String / 6 The six-digit alphanumeric authorization or approval code. <AUTHCODE>
<AUTHORIZEDAMOUNT>
<AVS_RESULT_CODE>
<BANK_ACCOUNTNAME>
<BANK_ACCOUNTTYPE>
Decimal / 15 Authorized Transaction Amount.
String / 2 Address Verification System Result Code.
See Appendix
String / 50
String / 8
<BATCHID>
<CARD_CODE_RESPONSE_CO
DE>
String / 15
String / 2
<CARDHOLDER_FIRSTNAME> String / 50
<CARDHOLDER_LASTNAME> String / 50
<CARDLEVEL_RESULTS> String / 10
<CARDTYPE> String / 10
Name of Account holder
Echoed from TRANSACTION
Default = 0, otherwise the Batch number of the transaction
Response code from Credit Card Identification Code verification.
See Appendix
First Name of Card Holder(Track Data required)
Last Name of Card Holder (Track Data required)
Additional information about the credit card type.
See Appendix
Card Type Code is returned.
See Appendix
<CASHBACK_AMOUNT>
<CAVV_RESPONSE_CODE>
<CHECKNUM>
<CODE>
<CUSTOMERID>
<EXPIRYDATE>
<GRATUITY>
<INDUSTRYSPECIFICDATA>
<LAST4DIGITS>
<LEVEL2_VALID>
Decimal / 15 Cash Back Amount echoed from TRANSACTION
String / 2 Indicates the results of Cardholder Authentication Verification
Value (CAVV) verification.
See Appendix
String / 20 Echoed from TRANSACTION
String / 4
String / 25
Echoed from TRANSACTION
Echoed from TRANSACTION
String / 4 Echoed from TRANSACTION
Decimal / 15 Echoed from TRANSACTION
String / 1 Echoed from TRANSACTION
String / 4
String / 5
Last 4 digits of card or bank account number
Is Level 2 valid
Reference
54
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length Notes
<LEVEL3_VALID>
<MARKETSPECIFICDATA>
<METHOD>
<NETWORKCODE>
<NETWORKID>
<OrderID>
String / 5
String / 1
String / 7
String / 10
String / 10
String / 25
Is Level 3 valid
Echoed from
Echoed from
TRANSACTION
TRANSACTION
Network Code for DB transactions
Transaction Identifier for Authorization Network.
Echoed from TRANSACTION
<PAYMENTID> String TRANSACTION
<RESPONSE_CODE> String / 3 Transaction Response Code. See Appendix
<RESPONSE_REASON_CODE> String / 6 Code for providing more details about the result of the transaction.
<RESPONSE_REASON_TEXT> String / 200 Brief description of the result, which corresponds to the Response
Reason Code.
<RESPONSE_SUBCODE>
<RETREFERENCENUM>
<SECURENETID>
<SETTLEMENTAMOUNT>
<SETTLEMENTDATETIME>
<SYSTEM_TRACENUM>
String / 6
String / 50
Integer / 8
String / 50
Code used by the system for internal transaction tracking.
Bank authorization reference #
Echoed from TRANSACTION
Decimal / 15 Settlement amount of Transaction
String / 14 Settlement date of transaction (MMDDYYYYHHMMSS).
System Trace # for Authorization Network
<TRACKTYPE>
<TRANSACTIONAMOUNT>
<TRANSACTIONDATETIME>
String / 1
String / 14
Track Type used for transaction, 0 if no track data is present
Decimal / 15 Echoed from TRANSACTION . For 0906—INQUIRY_BALANCE transactions this field indicates the available balance on the gift card.
Transaction date and time as recorded in the Gateway according to merchant time zone. (MMDDYYYYHHMMSS)
<TRANSACTIONID>
<CUSTOMER_BILL>
</ TRANSACTIONRESPONSE>
Integer / 15 System Generated Unique ID for transaction. Used to submit a modification of this transaction at a later time, such as voiding, crediting or capturing the transaction.
Object / 1 Echoed from TRANSACTION
Reference
9.1.1.3 VAULTACCOUNTRESPONSE
This object defines the information that will be sent by the Gateway as a response for all SecureNet Vault
Account transactions.
NOTE: All fields in the VAULTACCOUNTRESPONSE object are returned in a leftjustified, space-filled format.
XML Tag
Data Type /
Max Length
<VAULTACCOUNTRESPONSE> Object / 1
<RESPONSE_CODE> String / 10
<RESPONSE_REASON_CODE> String / 10
<RESPONSE_REASON_TEXT> String / 200
<RESPONSE_SUBCODE> String / 10
Notes
Response for SecureNet Vault Account Transactions.
Transaction Response Code. See Appendix .
Code for providing more details about the result of the transaction.
Reference
Brief description of the result, which corresponds with the
Response Reason Code.
Code used by the system for internal transaction tracking.
55
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
<ACCOUNTTYPE>
<ADDITIONALDATA1>
<ADDITIONALDATA2>
<CARDTYPE>
<COMPANY>
<CUSTOMERID>
<FIRSTNAME>
<LAST4DIGITS>
<LASTNAME>
<METHOD>
<PAYMENTID>
<TRANSACTIONDATETIME>
</VAULTACCOUNTRESPONSE>
Data Type /
Max Length
String / 8
String / 100
String / 100
String / 10
String / 50
String / 25
String / 50
String / 4
String / 50
String / 7
String / 25
String / 14
Notes
Echoed from ACCOUNT_VAULT
Contains TransactionID, which is generated while verifying an account before adding/updating Vault account information.
Future Use
Card Type Code is returned. See Appendix
Echoed from ACCOUNT_VAULT
Contains the customer ID associated with the transaction or record
Echoed from ACCOUNT_VAULT
ACCOUNT_VAULT
Last 4 digits of card or bank account.
Echoed from
Echoed from ACCOUNT_VAULT
Contains the Payment ID associated with the customer record
Transaction date and time as recorded in the Gateway according to merchant time zone. (MMDDYYYYHHMMSS).
Reference
9.1.1.4 VAULTCUSTOMERRESPONSE
XML Tag
<VAULTCUSTOMERRESPONSE> Object / 1
<RESPONSE_CODE> String / 10
<RESPONSE_REASON_CODE> String / 10
<RESPONSE_REASON_TEXT>
<RESPONSE_SUBCODE>
Data Type /
Max Length
String / 200
String / 10
Notes
Response for SecureNet Vault Account Transactions.
Transaction Response Code. See Appendix .
Code for providing more details about the result of the transaction.
Brief description of the result, which corresponds with the
Response Reason Code.
Code used by the system for internal transaction tracking.
<CUSTOMERID> String
<FIRSTNAME> String
</VAULTCUSTOMERRESPONSE
>
From CUSTOMER_BILL
Transaction date and time as recorded in the Gateway according to merchant time zone. (MMDDYYYYHHMMSS).
Echoed
Reference
9.1.1.5 P2PRESPONSE
This object defines the information that will be sent by the Gateway as a response when requesting a new P2P
Encryption Key or the Current Active Primary or Secondary P2P Encryption Key.
NOTE: All fields in the P2PResponse object are returned in a left-justified format.
56
SecureNet Gateway Implementation Guide 4.1.5
<KEYID>
XML Tag
<P2PRESPONSE>
<COMFIRMCODE>
<CONFIRMATIONNUMBER>
<EXPDATE>
<KEY>
<RESPONSE_SUBCODE>
<STATUS>
</ P2PRESPONSE >
Data Type /
Max Length Required
Object
String/ 16
String/10
String/8
Object of P2P
PUBLIC KEY
Integer
True
True
True
True
True
<RESPONSE_REASON_CODE> String / 4
String / 4
Integer
True
False
True
Notes
The confirmation string of a P2P Encryption key.
The confirmation number of a P2P Encryption key.
The date that the P2P Encryption key is set to expire.
The public key portion of a P2P Encryption key.
The unique identifier of the P2P Encryption key.
Declined, or an Error.
The unique identifier of the RESPONSE_REASON_TEXT
The
The sub-code that categorizes a RESPONSE_CODE
The current status of the P2P Encryption key.
Reference
9.1.1.6 P2P_PUBLIC_KEY
This object defines the P2P Encryption Public Key information that is used by the client.
XML Tag
Data Type /
Max Length
< P2P_PUBLIC_KEY>
<Exponent> String / 4
<Modulus>
</ P2P_PUBLIC_KEY>
String / 172
Notes Reference
Available through:
The Exponent variable used for calculating the encryption key. Extended services
The Modulus variable used for calculating the encryption key. Extended services
9.1.1.7 IMAGERESPONSE
This object defines the information that will be sent by the Gateway as a response when requesting to update the transaction.
XML Tag
<TRANSACTIONID>
Data Type /
Max Length Required
Integer / 15 True
Notes
System Generated Unique ID for corresponding transaction, returned by the Gateway.
Reference
9.2 Response Objects for Settlement Transactions
9.2.1
BATCHDATA Object Structure
BATCHDATA
BATCHDETAILS
57
SecureNet Gateway Implementation Guide 4.1.5
9.2.1
BATCHDATA Object Specification
This section details high-level BATCHDATA Object specification. Descriptions, rules and notes for each object of
BATCHDATA are detailed below:
XML Tag
<BATCHDATA>
</BATCHDATA>
Data Type /
Max Length Notes of Refer Object.
Reference
9.2.1.1 BATCHDETAIL
This object defines the information that can be submitted to the Gateway for Settlement Transactions.
XML Tag
<BATCHDETAIL>
<BatchId>
<METHOD>
<SECURENETID>
Data Type /
Max Length
String / 20
String
String / 20
<TOTALBATCHAMOUNT> String / 20
<TOTALCREDITAMOUNT> String / 20
<TOTALSALEAMOUNT> String / 20
<TOTALTRANSACTIONS> String / 20
<BATCHDETAIL>
Notes
Batch ID created on Batch Close
Should be the value returned by the Gateway
CC, DB, ECHECK
2—Paymentech
3—SecureNet Frontend
5—Nashville
7-digit unique SecureNet ID provided by SecureNet to identify the merchant and is required for each submitted transaction
If a SecureNet ID is needed contact SecureNet
Total Amount of Batch (Sales less Credits)
Total Amount of Credit
Total Amount of Sale
Number of transactions
References
This object contains individual batch information, like Batch ID created on Batch Close, number of transactions in a batch, etc.
9.2.1.2 BATCHDATA Message Format
XML Tag
<BATCHDATA>
<BATCHCOUNT>
<BATCHDETAILS>
Data Type /
Max Length
String
Object Array
Notes
Number of batches
Array of BATCHDETAIL objects
Reference
BATCHDETAIL
58
SecureNet Gateway Implementation Guide 4.1.5
XML Tag
Data Type /
Max Length
<SECURENETID> Integer / 8
</BATCHDATA>
Notes
7-digit unique SecureNet ID provided by SecureNet to identify the merchant and is required for each submitted transaction
Property Name
BATCHDATA
BATCHDETAIL
Type
Object
Object
Description
Superset and Response object for Batches created
Subset of Batch data with Individual Batch Details
Object is returned only if Batches are created and transactions exist to create a batch
Reference
Reference
9.2.1.3 VAULTCUSTOMERRESPONSE
Please note that all fields in the VAULTCUSTOMERRESPONSE object are returned in a left-justified, spacefilled format.
XML Tag
Data Type /
Max Length
<VAULTCUSTOMERRESPONSE>
<COMPANY> String / 50
<CUSTOMERID> String / 25
<FIRSTNAME>
<LASTNAME>
<RESPONSE_CODE>
<RESPONSE_REASON_CODE>
<RESPONSE_REASON_TEXT>
<RESPONSE_SUBCODE>
<TRANSACTIONDATETIME>
</VAULTCUSTOMERRESPONSE>
String / 50
String / 50
String / 10
String / 10
String / 200
String / 10
String / 14
Notes
Echoed from CUSTOMER_VAULT
Contains the customer ID associated with the transaction or record
Echoed from CUSTOMER_VAULT
Echoed from CUSTOMER_VAULT
Transaction Response Code
See Appendix
Code for providing more details about the result of the transaction
Brief description of the result, which corresponds with the Response Reason Code
Code used by the system for internal transaction tracking
Transaction date and time as recorded in the Gateway according to merchant time zone
(MMDDYYYYHHMMSS)
Reference
59
SecureNet Gateway Implementation Guide 4.1.5
APPENDIX A: GATEWAY RESPONSE
A. Account Duplicate Check Indicator (ADCI)
Account Duplicate Check Indicator—Indicates whether duplicate account exists.
0 - Does not check for Duplicate Card Number for specified Customer ID
1 - Checks for Duplicate Card Number for specified Customer ID
2 - Checks for Duplicate Card Number for All Customer IDs for specified SecureNet ID
3 - Checks for Duplicate Card Number for All Customer IDs for specified Group ID
NOTE: For ACCOUNT_VAULT only. Set to 0 by default. a. AVS_RESULT_CODE
Indicates the result of Address Verification System (AVS) checks.
The Address Verification System (AVS) helps merchants detect suspicious transaction activity. To use this system, the merchant must submit the customer’s credit card billing address (numeric value only) to the Gateway for validation. This information is submitted by the Gateway to the financial institutions. The financial institutions compare the submitted address with the billing address on file for that particular credit card and return an AVS response code to the Gateway. The Gateway includes this code in the response back to the merchant.
AVS Code
P
R
S
T
I
M
N
C
D
E
G
0
A
B
U
W
X
Y
Z
Description
AVS data not provided
Street address matches, Zip Code does not
Postal code not verified due to incompatible formats
Street address and postal code not verified due to incompatible formats
Street address and postal code match
AVS data is invalid
Non-U.S. issuing bank does not support AVS
Address information not verified by international issuer
Customer Name, Billing Address and Zip match
Neither street address nor Zip code match
Street address not verified due to incompatible format
Retry: issuer's system unavailable or timed-out
U.S. issuing bank does not support AVS
Street address does not match, but 9-digit Zip code matches
Address information is unavailable
9-digit Zip matches, street address does not
Street address and 9-digit Zip match
Street address and 5-digit Zip match
5-digit Zip matches, street address does not
NOTE: It is recommended that merchants enable some level of Address Verification to avoid non-qualified transaction surcharges that can be levied by merchant banks and merchant service providers.
60
SecureNet Gateway Implementation Guide 4.1.5
b. CARD_CODE_RESPONSE_CODE
(CVV2/CVC2/CID) The Credit Card Identification Code, or “Card Code,” is a three- or four-digit security code that is printed on the back of credit cards in reverse italics in the card’s signature panel (or on the front for American
Express cards). The merchant can collect this information from the customer and submit the data to the Gateway.
The Gateway will pass this information to the financial institution along with the credit card number. The financial institution will determine if the value matches the value on file for that credit card and return a code indicating whether the comparison failed or succeeded. The Gateway passes back this response code to the merchant.
Code Description
0 CVV/CID not provided
M Match
S
U
Y
Data not present
Issuer unable to process request
Card Code Matches (Amex Only) c. CARDLEVEL_RESULTS
This table provides additional information on card type:
NOTE: MasterCard results are available only for SecureNet Frontend, First Data
Nashville and TSYS processor.
Code Description
AX1
B
American Express
Visa Traditional Rewards
D
DI1
E –F
Visa Signature Preferred
Discover
Reserved
G1
G2
G3
Visa Signature Business
Visa Business Check Card
Visa Business Enhanced
H
Visa Debit
Visa Check Card
Visa Debit
I Reserved
J Reserved
J1 Visa General Prepaid
J2 Visa Prepaid Gift
J3
J4
Visa Prepaid Healthcare
Visa Prepaid Commercial
61
SecureNet Gateway Implementation Guide 4.1.5
K1
Code Description
Visa GSA Corporate T&E
L Reserved
M MasterCard/EuroCard
N –P Reserved
Q1 Private Label Prepaid
R Proprietary
S1
S2
Visa Purchasing with Fleet
Visa GSA Purchasing
S3 Visa GSA Purchasing with Fleet
T Reserved
V1
W –Z
O –9
Reserved
Reserved
Reserved
Provides additional information on MasterCard type:
DLG
DLH
DLI
DLS
MAB
MAC
Code Description
Debit MasterCard Gold—Delayed Debit
Debit MasterCard World Embossed—Delayed Debit
Debit MasterCard Standard ISIC Student Card—Delayed Debit
Debit MasterCard Card—Delayed Debit
World Elite MasterCard Business
MasterCard Corporate World Elite
MBE
MCA
MCB
MCE
MCF
MCG
MCH
MCM
MCP
MCS
MasterCard Electronic Business Card
MasterCard Electronic Basic Card
MasterCard BusinessCard Card MasterCard Corporate Card
MasterCard Electronic Card
MasterCard Corporate Fleet Card
Gold MasterCard Card
MasterCard Premium Charge
MasterCard Corporate Meeting Card
MasterCard Corporate Purchasing Card
MasterCard Standard Card
62
SecureNet Gateway Implementation Guide 4.1.5
MDM
MDN
MDO
MDP
MDQ
MDT
MDU
MEB
MEC
MED
MEF
MEO
MEP
MFB
MFE
MIB
MIC
MID
MIG
MIH
MIJ
MIK
MFL
MFW
MGF
MHA
MHB
NHC
MHH
MIL
MIP
MIS
MIU
MCW
MDB
MDG
MDH
MDJ
Code Description
World MasterCard Card
Debit MasterCard BusinessCard Card
Debit Gold MasterCard
World Debit Embossed
Debit- Debit Other 2 Embossed
Middle Market Fleet Card
Middle Market Purchasing Card
Debit MasterCard Other
Debit MasterCard Platinum
Middle Market Corporate Card
MasterCard Business Debit
Debit MasterCard Unembossed
MasterCard Executive BusinessCard Card
MasterCard Electronic Commercial
Debit MasterCard Electronic
MasterCard Electronic Payment Account
MasterCard Corporate Executive Card
Premium Debit MasterCard
Flex World Elite
Flex charge World Elite
Flex Charge Platinum
Flex Charge World
MasterCard Government Commercial Card
MasterCard Healthcare Prepaid Non-tax
MasterCard HAS Substantiated
MasterCard Healthcare Credit Non-substantiated
MasterCard Unembossed Prepaid Student card
MasterCard Credit Electronic Student Card
MasterCard Credit Standard Student Card
MasterCard Debit Unembossed Student Card
MasterCard Credit Umembossed Student Card
MasterCard Electronic Consumer Non U.S. Student Card
MasterCard Debit Unembossed Non U.S. Student Card
MasterCard Electronic Consumer Prepaid Non U.S Student Card
MasterCard Unembossed Prepaid Non U.S Student Card
MasterCard Debit Prepaid Student Card
MasterCard Debit Standard Student Card
Debit MasterCard Unembossed Outside US
63
SecureNet Gateway Implementation Guide 4.1.5
MLA
MLC
MLD
MLL
Code
MNW
MPA
MPB
MPC
MPF
MPG
MPJ
MPK
MPL
MPM
MPN
MPO
MPR
MPT
MPV
MPW
MPY
MPZ
MRB
MRC
Description
MasterCard Central Travel Solutions Air
MasterCard Micro-Business Card
MasterCard Distribution Card
MasterCard Central Travel Solutions Land
World MasterCard Card (Europe)
Prepaid MasterCard Payroll Card
MasterCard Preferred BusinessCard
MasterCard Professional Card
Prepaid MasterCard Gift Card
Prepaid MasterCard Consumer Reloadable Card
Prepaid Debit MasterCard Card Gold
Prepaid MasterCard Government Commercial Card
Platinum Mastercard Card
Prepaid MasterCard Consumer Promotion Card
Prepaid MasterCard Insurance Card
Prepaid MasterCard Other Card
Prepaid MasterCard Travel Card
Prepaid MasterCard Teen Card
Prepaid MasterCard Government Benefit Card
Prepaid MasterCard Corporate Card
Prepaid MasterCard Employee Incentive Card
Prepaid MasterCard Emergency Assistance Card
Prepaid MasterCard Electronic BusinessCard
Prepaid MasterCard Electronic Card
MRH
MRJ
MRK
MRO
MRP
MRS
MRW
MSD
MUP
MUS
MUW
MasterCard Platinum Prepaid Travel Card
Prepaid MasterCard Gold Card
Prepaid MasterCard Public Sector Commercial Card
MasterCard Rewards Only
Standard Retailer Centric Payments
Prepaid MasterCard ISIC Student Card
Prepaid MasterCard BusinessCard Credit Outside US
Deferred Debit MasterCard
Premium Debit MasterCard Unembossed
Prepaid MasterCard Unembossed US
MasterCard World Domestic Affluent
64
SecureNet Gateway Implementation Guide 4.1.5
PVD
PVE
PVF
PVG
PVH
PVI
PVJ
SUR
MWE
MWO
MWR
PVA
PVB
PVC
Code
TCB
TCC
TCE
TCF
TCG
TCP
TCW
TDN
TEB
TEC
TEO
TIB
TIC
TIU
TLA
TNF
TNW
TPB
TPC
TPL
Description
MasterCard World Elite
MasterCard Corporate World
World Retailer Centric Payment
Private Label 1
Private Label 2
Private Label 3
Private Label 4
Private Label 5
Private Label 6
Private Label 7
Private Label 8
Private Label 9
Private Label 10
Prepaid MasterCard Unembossed Outside US
MasterCard Business Card—Immediate Debit
MasterCard (Mixed BIN) —Immediate Debit
MasterCard Electronic —Immediate Debit
MasterCard Fleet Card —Immediate Debit
Gold MasterCard Card —Immediate Debit
MasterCard Purchasing Card—Immediate Debit
World Signia MasterCard Card —Immediate Debit
Middle Market MasterCard Purchasing Card —Immediate Debit
MasterCard Executive BusinessCard Card —Immediate Debit
MasterCard Electronic Commercial —Immediate Debit
MasterCard Corporate Executive Card —Immediate Debit
ISIC MasterCard Electronic Student Card —Immediate Debit
ISIC MasterCard Standard Student Card —Immediate Debit
MasterCard Unembossed —Immediate Debit
MasterCard Central Travel Solutions Air—Immediate Debit
MasterCard Public Sector Commercial Card —Immediate Debit
MasterCard New World —Immediate Debit
MasterCard Preferred Business Card —Immediate Debit
MasterCard Professional Card —Immediate Debit
Platinum MasterCard —Immediate Debit
65
SecureNet Gateway Implementation Guide 4.1.5
d. CAVV_RESPONSE_CODE
Indicates the results of Cardholder Authentication Verification Value (CAVV) verification.
Code
8
9
6
7
A
B
Blank
0
1
2
3
4
5
Description
CAVV not validated
CAVV not validated because erroneous data was submitted
CAVV failed validation
CAVV passed validation
CAVV validation could not be performed; issuer attempt incomplete
CAVV validation could not be performed; issuer system error
Reserved for future use
Reserved for future use
CAVV attempt—failed validation—issuer available (U.S.-issued card/non-U.S acquirer)
CAVV attempt—passed validation—issuer available (U.S.-issued card/non-U.S. acquirer)
CAVV attempt—failed validation—issuer unavailable (U.S.-issued card/non-U.S. acquirer)
CAVV attempt—passed validation—issuer unavailable (U.S.-issued card/non-U.S. acquirer)
CAVV passed validation, information only, no liability shift
The CARDTPYE Code is a system-specific code for different types of cards as identified by the Gateway.
Reference CARDTYPE Code Response Description
ACH e-Check
DS Discover
EBT Electronic
GC Gas Card (Fuelman)
JC JCB
MC MasterCard
SV Stored Value Card
VI Visa
VY Voyager
WX Wright Express (WEX) Card
66
SecureNet Gateway Implementation Guide 4.1.5
f . DCI
Duplicate Transaction Indicator must be activated in Tools tab of the Virtual Terminal: "Duplicate Transaction Lockout
Settings". Duplicates are evaluated against AMOUNT, CARDNUMBER, and, optionally, a user defined field (like
Customer ID, Invoice Number or one of the UDFs), and within a specified time frame of only APPROVED transactions, unless otherwise noted. If a duplicate transaction is found the new transaction is not reprocessed.
0 No duplicate checking will be done.
1 If evaluation of the above conditions results in a duplicate transaction an exception code will be returned.
2 If evaluation of the above conditions results in a duplicate transaction the original transaction response is returned with RESPONSE_REASON_TEXT = “Approved”.
3 Identical to 1 however OrderID is not evaluated.
NOTE: After the above duplicate check is evaluated and no duplicate is found, then
OrderID will be evaluated and responses sent accordingly.
For eCommerce transactions:
P - Physical goods
D - Digital goods
For MO/TO transactions:
1 - Single purchase transaction (AVS is required)
2 - Recurring billing transaction (do not submit AVS)
3 - Installment transaction
For Retail transactions—leave blank.
NOTE: If TRANSACTION_SERVICE = 1 (Process using Customer ID) or 2 (Process using Secondary Merchant ID), INDUSTRYSPECIFICDATA will be set to 1 by default, unless transaction request specifies otherwise.
C. METHOD
Method indicates the method of payment for the transaction being sent to the system and can be one of the following
(The following values are case sensitive):
Reference Code Description
DB Debit
67
SecureNet Gateway Implementation Guide 4.1.5
a. OrderID
A client generated unique ID for each transaction submitted to the Gateway. OrderID must be unique to the
SecureNet ID; however the uniqueness is only evaluated for APPROVED transactions and only for the last
30 days. If a transaction results in a decline that OrderID may be used again. The OrderID is used as a default method to avoid processing duplicate transactions. The OrderID is not verified for transaction types such as VOID and 0200-PRIOR_AUTH_CAPTURE . OrderID is limited to 25 characters; for example
“CUSTOMERID MMddyyyyHHmmss”.
Format—Alphanumeric values only, No spaces and no special characters b. REF_TRANSID
Transaction ID is a unique value provided by SecureNets Gateway in response for all transactions (approved and declined). This value can be used to reference a previously processed transaction for further processing like to void an approved transaction, capture a 0000—AUTH_ONLY transaction etc.
REF_TRANSID is required information for 0200—PRIOR_AUTH_CAPTURE, 0400 — VOID Transaction and
0500-CREDIT.
It is possible to “re-use” account information (Credit Card, Bank account information, etc.) from an authorized transaction to [process a new transaction i.e. retrieve credit card information from a previously approved transaction and use this information to submit a new transaction. If the REF_TRANSID value is set in the
TRANSACTION object using a previously approved transaction’s Transaction ID, a credit card number is not required to be sent, the credit card number from the transaction referenced by REF_TRANSID will be used.
In order to re-use account information to process a new transaction, please follow the instructions below:
1. REF_TRANSID should be present. CARDNUMBER, ACCOUNTNUM, TRACKDATA, or MICRDATA should not be present.
2. Last 4 digit of card number or account number should be available
3. REF_TRANSID can be from a previously approved transaction.
4. REF_TRANSID should not be older than 180 days for the SecureNet ID.
5. Re-using account information from an approved transaction is available for the following transaction codes: a. 0100—AUTH_CAPTURE,0000—AUTH_ONLY,0300—CAPTURE_ONLY, b. Re-using account information cannot be done for a Card-Present transaction, i.e.
INDUSTRYSPECIFICDATA in the TRANSACTION object should not be empty or null, it should be set to 1, 2, 3, P, or D. c. RESPONSE_CODE
Indicates the result of the transaction:
1 —Approved
2 —Declined
3 —Error / Invalid Data d. SECCODE
The Standard Entry Class (SEC) code is a three letter code that identifies the nature of the ACH entry. Here are some common SEC codes:
Code Description
ARC Accounts Receivable Entries A check received by a merchant through mail or drop box and presented as an ACH entry. Business Checking account, Personal Savings and Personal
Checking accounts are only allowed
68
SecureNet Gateway Implementation Guide 4.1.5
Code Description
BOC Back Office Conversion A check that is converted from paper to an electronic debit at a centralized location and presented as an ACH entry. Business Checking account, Personal
Savings and Personal Checking accounts are only allowed
CCD Corporate Cash Disbursement Primarily used for business to business transactions. Business
Checking account is only allowed. Credits can only be processed using CCD for Business Accounts
POS Point-of-Sale A debit at electronic terminal initiated by use of a plastic card. An example is using a
Debit card to purchase gas. Personal Savings and Personal Checking accounts are only allowed
PPD Prearranged Payment and Deposits Used to credit or debit a consumer account. Popularly used for payroll direct deposits and preauthorized bill payments. Personal Savings and Personal Checking accounts are only allowed. Credits can only be processed using PPD for Personal Accounts.
TEL Telephone Initiated-Entry Verbal authorization by telephone to issue an ACH entry such as checks by phone. (TEL code allowed for inbound telephone orders only. NACHA disallows the use of this code for outbound telephone solicitations calls). Personal Savings and Personal
Checking accounts are only allowed
WEB Web Initiated-Entry Electronic authorization through the Internet to create an ACH entry. Bank
Account Holder First and Last Name are required. Personal Savings and Personal Checking accounts are only allowed
POP Business Checking account, Personal Savings and Personal Checking accounts are only allowed
Please note that “Linked Credit transactions can be processed only if the original transaction used the following
SEC codes; PPD, POS, WEB, TEL and CCD”.
CODE : Transaction Type Code The following table describes the Codes of transactions that can be submitted to the Gateway and how the Gateway will process them.
CODE Transaction Type
0000 AUTH_ONLY
0001 PARTIAL_AUTH_ONLY
Description
Used to validate a credit card for the amount of goods sold. The
Gateway will send this type of transaction to the financial institution for approval. However this transaction will not be sent for settlement. If the merchant does not act on the transaction within 30 days, the transaction will no longer be available for capture.
Available for:
Credit
Prepaid
StoredValueCard for Ceridian
Used ONLY to validate a prepaid card for the amount of goods sold and may return an amount less than the requested amount if the total amount cannot be fully authorized. The Gateway will send this type of transaction to the financial institution for approval. However this transaction will not be sent for settlement. If the merchant does not act on the transaction within 30 days, the transaction will no longer be available for capture.
Available for:
Prepaid
Nashville platform only
Reference
69
SecureNet Gateway Implementation Guide 4.1.5
CODE Transaction Type
0100 AUTH_CAPTURE
0101 PARTIAL_AUTH_CAPTURE
0200 PRIOR_AUTH_CAPTURE
0201 UPDATE_TRANS_INFO
Description
Identical to AUTH_ONLY(0000); however on approval the transaction will be picked up for settlement.
Available for:
E-checks
Credit
PIN
PIN-less
Prepaid
StoredValueCard for Ceridian
EBT
Identical to PARTIAL_AUTH_ONLY(0101); however on approval the transaction will be picked up for settlement.
Available for:
Prepaid
Credit Cards on TSYS and SecureNet FrontEnd platforms
This transaction is used to request settlement for a transaction that was previously submitted as an AUTH_ONLY( 0000). The Gateway will accept this transaction and initiate settlement if the following conditions are met:
The transaction is submitted with the ID of the original authorizationonly transaction to be settled.
The transaction ID is valid and the system has a record of the original authorization-only transaction.
The original transaction referred to is not already settled, expired, or voided.
The amount being requested for settlement is less than or equal to the original authorized amount.
If no amount is submitted in this transaction, the Gateway will initiate settlement for the amount originally authorized. Merchant account set up as Retail cannot capture an amount greater than the authorized amount (AUTH_ONLY(0000) to PRIOR_AUTH_CAPTURE(0200)).
NOTE:
If extended line item, tax, freight, and/or duty information was submitted with the original transaction, adjusted information may be submitted in the event that the transaction amount changed. If no adjusted line item, tax, freight, and/or duty information is submitted, the information submitted with the original transaction will apply.
Available for:
E-checks*
Credit
Check
Prepaid
StoredValueCard for Ceridian
To update Level II and Level III information for qualified transaction before settlement and for updating the image for Check 21 and image for ACH signature.
Reference
70
SecureNet Gateway Implementation Guide 4.1.5
CODE Transaction Type
0300 CAPTURE_ONLY
0400 VOID
0401 PARTIAL_VOID
Description
This is a request to settle a transaction that was not submitted for authorization through the payment Gateway. The Gateway will accept this transaction if an authorization code is submitted.
AUTHCODE is a required field for CAPTURE_ONLY(0000) transactions.
Available for:
Credit
Check
Prepaid
EBT
This action cancels a previous transaction such that it is not sent for settlement. It can be performed on the following transaction types:
CREDIT(
AUTH_CAPTURE(0100)
CAPTURE_ONLY(0300)
AUTH_ONLY
The transaction will be accepted by the Gateway if the following conditions are met:
The transaction is submitted with the ID of the original transaction to be voided (REF_TRANSID).
The card number (or the last four digits thereof) submitted with the credit transaction matches the card number of the original transaction.
The Gateway has a record of the transaction referenced by the ID.
The transaction has not been sent for settlement.
Available for:
E-checks
Credit
Check
Prepaid
All
This action will reduce the amount of a previous unsettled transaction.
The transaction is submitted with the ID of the original transaction to be voided (in REF_TRANSID field).
The Gateway has a record of the transaction referenced by
REF_TRANSID.
The card number (or the last four digits thereof) submitted with the credit transaction matches the card number of the original transaction.
The transaction has not been sent for settlement.
Available for:
E-checks
Credit
Check
Prepaid
MOTO and E-Commerce merchants only
Nashville platform only, TSYS in pipeline
Reference
71
SecureNet Gateway Implementation Guide 4.1.5
CODE Transaction Type
0402 VOID_BY_OrderID
0500 CREDIT
Description
This action cancels a previous transaction such that it is not sent for settlement. It can be performed on unsettled transactions of the following types:
AUTH_ONLY(0000)
AUTH_CAPTURE(0100)
PRIOR_AUTH_CAPTURE(0101)
CREDIT_AUTHONLY(0501)
FORCE_CREDIT(0600)
The transaction will be accepted by the Gateway if the following conditions are met:
The transaction is submitted with the OrderID of the original transaction to be voided (in OrderID field).
The card number (or the last four digits thereof) submitted with the credit transaction matches the card number of the original transaction.
The Gateway has a record of the transaction referenced by the
OrderID.
The transaction has not been sent for settlement.
Available for:
E-checks
Credit
Check
Prepaid
All
This transaction is also referred to as a “Refund” and indicates to the
Gateway that money should flow from the merchant to the customer.
The Gateway will accept a credit (refund) request if the transaction submitted meets the following conditions:
The transaction is submitted with the ID of the original transaction against which the credit is being issued (REF_TRANSID).
The transaction ID is valid and the system has a record of the original transaction.
The original transaction has been settled.
The sum submitted in the credit transaction and all credits submitted against the original transaction is less than or equal to the original transaction amount.
The card number (or the last four digits thereof) submitted with the credit transaction matches the card number of the original transaction.
The credit transaction is submitted within 180 days of the settlement date and time of the original transaction.
**Transactions are captured if approved
Available for:
E-checks
Credit
Check
Prepaid
Debit cards for SecureNet Front End with Pin Data
StoredValueCard for Ceridian
EBT
Reference
72
SecureNet Gateway Implementation Guide 4.1.5
CODE Transaction Type
0501 CREDIT_AUTHONLY*
Description
0600 FORCE_CREDIT Similar to CREDIT(0500) used for Unlinked credits when previous
Authorized Transaction is not Available. This feature has to be enabled by Merchant Service Provider on the Gateway. Full Account
Number should be provided
**Transactions are captured if approved
Available for:
E-checks
Credit
Prepaid
StoredValueCard for Ceridian
EBT
0602 FORCE_CREDIT_PRIORAUTHCAP
TURE*
0700 VERIFICATION
Future use
0800 AUTH_INCREMENT
0900 ISSUE
Run Transaction Verification on Credit Card or Bank Account with zero dollar amount.
For Certegy ECHECK verification can be done for non-zero amount also.
Available for:
Nashville
TSYS
SecureNet FrontEnd platforms
Credit
E-checks
This action performs an incremental authorization on a previously authorized transaction (i.e., AUTH_ONLY). Only applicable to Visa transactions and only if the terminal has been set up as LODGING or
AUTO RENTAL industry type. The transaction will be accepted by the
Gateway if the following conditions are met:
The transaction is submitted with the ID of the transaction.
The Gateway has a record of the transaction referenced by the ID.
The transaction has not been sent for settlement.
AUTH_INCREMENT(0800) can be submitted multiple times before submitting PRIOR_AUTH_CAPTURE(0101).
This action issues a new card or adds funds to an already activated stored value card for paymentech platform and issues a card for
Ceridian platform; also used for refunds to a stored value card for paymentech platform. Will be treated as credit to the card holder.
Available for:
Pre-paid Cards/Stored Value Cards only
Ceredian and Paymentech platform
Reference
73
SecureNet Gateway Implementation Guide 4.1.5
CODE Transaction Type
0901 ACTIVATE
0902 REDEEM
0903 REDEEM_PARTIAL
0904 DEACTIVATE
0905 REACTIVATE
0906 INQUIRY_BALANCE
0907 RELOAD/ RECHARGE
0908
0909
0201
ISSUE_VIRTUAL
CASH_OUT
UPDATE TRANSACTION
INFORMATION
Description
This action activates a new card; only necessary if the stored value card is set to require activation.
Available for:
Pre-paid
Paymentech
Ceridian
This action charges a card; the amount has to be within the available balance.
Available for:
Pre-paid
Paymentech
Ceridian
This action charges a card; the card will be approved only for the available balance on the card if the transaction is approved.
Available for:
Pre-paid only
Paymentech platform only
This action de-activates an activated card; amount should be specified as zero.
Available for:
Pre-paid only
Paymentech platform only
This action re-activates a de-activated card.
Available for:
Pre-paid only
Paymentech platform only
This action checks the available balance on the stored value card; amount should be specified as zero. The available balance on the gift card will be returned in the TRANSACTIONAMOUNT field in the
TRANSACTIONRESPONSE object.
Available for:
Pre-paid only
Paymentech platform only
Ceridian
Adds value to a card
Available for Ceridian
Pre-paid Cards/Stored Value Cards only
Ceredian platform
This will issue a Virtual Card number and PIN. No plastic exists.
Available for Ceridian
This will withdraw all the available balance from the card.
Available for Ceridian
This code enables updating Level2/Level3 transaction information of an approved transaction before it gets settled.
Also this is used for CHECK21 image update and SIGNATURE image update.
Both Image and Level2/Level3 information cannot be updated simultaneously.
Reference
74
SecureNet Gateway Implementation Guide 4.1.5
Displays a description in addition to the merchants DBA. This is currently restricted to credit card transactions only.
Contact Support to use this field. Maximum length is 25 characters.
The SOFTDESCRIPTOR field should contain the “Doing Business As” (DBA) name of the merchant and be the name most recognizable to the cardholder. The SOFTDESCRIPTOR field must not be used as a description field in lieu of the required, recognizable name. In addition, the SOFTDESCRIPTOR field may contain a merchandise description, order number, reference number, or other information that will further identify the transaction and assist cardholder recognition.
If additional information is used, the SOFTDESCRIPTOR field must conform to one of the following formats:
Option 1:
Option 2:
Option 3:
Field Position
Pos. 1–3:
Pos. 4:
Pos. 5–25:
Pos. 1–7:
Pos. 8:
Pos. 9–25:
Pos. 1–12:
Pos. 13:
Pos. 14–25:
Data
Merchant name or abbreviation
Asterisk (*)
Descriptive Information
Merchant name or abbreviation
Asterisk (*)
Descriptive Information
Merchant name or abbreviation
Asterisk (*)
Descriptive Information
F. TRACKDATA
This field contains information encoded from a valid magnetic stripe and includes data such as Primary Account
Number and Expiration Date. Unaltered Track Data must be forwarded intact. On Debit Card and EBT (Not Voucher
Clear) transactions, this field is mandatory (with the exception of Debit Card PIN-Less transactions, which are entered manually). Track Data may contain Track 1 and/or Track 2 data. Track 2 data is required for Pin Debit and
Stored Value transactions. Track 1 and Track2 data should not be submitted together. Gateway will also accept trackdata with beginning and end sentinel removed.
It is not acceptable to:
1. Use a manually entered account number and attempt to create a pseudo magnetic stripe.
2. Alter a Track 1 magnetic stripe and remove the cardholder name to make it look like a Track 2.
3. Flip the expiration date digits to MMYY order.
4. Truncate trailing spaces or zeroes.
5. Add, delete, or move characters in any way, including trailing spaces.
Accurate Track 1 or Track 2 data is required to receive Card Present rates. Authorization requests containing altered Track 1 or Track 2 data will be flagged as NOT COMPLIANT by Visa and MasterCard, resulting in the merchant paying the highest transaction rate and forfeiture of chargeback protection. Both associations monitor non-compliant transactions and will assess fines and penalties to merchants that are not in compliance.
The POS device or software must perform the following operations on Track read data before it can be used in an authorization request message:
The longitudinal redundancy checks (LRC) must be calculated for the data read from the Track and compared to the LRC read from the Track. The Track data is assumed to be read without errors when no character parity errors are detected and the calculated and read LRCs match.
The starting sentinel, ending sentinel, and LRC are discarded.
75
SecureNet Gateway Implementation Guide 4.1.5
The character codes read from the magnetic stripe must be converted from the encoded character set to the set used for the authorization request message. The characters encoded on Track 1 are six bit plus parity codes and the characters encoded on Track 2 are four bit plus parity codes, with the character set used for the request message defined as seven bit plus parity code. All characters read from a Track must be converted to the request message character set and transmitted as part of the request. The converted
Track data cannot be modified by adding or deleting non-framing characters and must be a one for one representation of the characters read from the Track.
NOTE: You only need to submit Track 1 or Track 2 data. If both tracks are sent by the
POS application, the Gateway will use the Track 1 information. If neither Track 1 nor
Track 2 data is submitted, but x_card_num and x_exp_date are submitted, the Card
Present transaction rate might be downgraded.
This is a variable length field with a maximum data length of 76 characters. The Track 1 data read from the cardholder’s card is checked for parity and LRC errors and then converted from the six-bit characters encoded on the card to seven bit characters as defined in ANSI X3.4.
As part of the conversion, the terminal must remove the framing characters (start sentinel, end sentinel, and
LRC characters). The separators must be converted to either an ASCII “^” (HEX 5E) or ASCII <US> (HEX 1F) characters. The entire unaltered Track, excluding framing characters, must be provided in the authorization request message or an error condition will result.
Track 1 can be encoded with up to 79 characters as shown below:
SVC
NAME FS DATE CD
DISCRETIONARY
LEGEND:
Field Description Length Format
PAN
NAME
(“B” for credit cards)
Primary Account Number
Card Holder Name
DATE
SVC CD
Expiration Date (YYMM)
Service Code
DISCRETIONARY DATA Optional Issuer Data
1 Alphanumeric
19 max Numeric
2 - 25 max
4
3
Variable
Alphanumeric
Numeric
Numeric
Alphanumeric
LRC Longitudinal Redundancy Check
Total cannot exceed 79 bytes
1
79 b. Track 2 Data
This is a variable length field with a maximum data length of 37 characters. The Track 2 data read from the cardholder’s card is checked for parity and LRC errors and then converted from the four-bit characters encoded on the card to seven bit characters as defined in ANSI X3.4. As part of the conversion, the terminal must remove the start sentinel, end sentinel, and LRC characters. The separators must be converted to either an
76
SecureNet Gateway Implementation Guide 4.1.5
ASCII “=” (HEX 3D) or ASCII “D” (HEX 44) characters. The entire UNALTERED Track (excluding framing characters) must be provided in the authorization request message or an error message will be generated.
Track 2 Data can be encoded with up to 40 characters as shown below:
CD ES LRC
LEGEND:
Field Description
PAN Primary Account Number
DATE Expiration Date (YYMM)
SVC CD Service Code
DISCRETIONARY DATA Optional Issuer Data
ES End Sentinel
LRC Longitudinal Redundancy Check
Total cannot exceed 40 bytes
Length
19 max
4
3
Variable
1
1
40
Format
Numeric
Numeric
Numeric
Alphanumeric
0F Hex
Field Name
ADDITIONALDATA1
ADDITIONALDATA2
ADDITIONALDATA3
ADDITIONALDATA4
Debit Cards EBT
Stored Value
Cards Fleet Cards
Paymentech specific data—For Debit
Transactions it will contain the Trace Number for the transaction. For PD transaction, settlement date is returned.
For EBT transactions it will contain the FNS
# echoed from the
ADDITIONALINFO field of the
MERCHANT_KEY object.
For EBT transactions it will contain the
Voucher # echoed from the
ADDITIONALINFO field of the CARD object.
Previous Balance (15 characters long zero filled decimal number with explicit decimal point) followed by
Cash Out Amount (15 characters long zero filled decimal number with explicit decimal point)
for ISSUE_VIRTUAL:
Virtual issued card number
Paymentech only—
Optional data returned by the Host for Fleet Cards. (If data exists, it must be printed on the customer receipt as reference data).
for ISSUE_VIRTUAL:
Virtual issued card
EXP date for ISSUE_VIRTUAL:
Virtual issued card
Pin Number
77
SecureNet Gateway Implementation Guide 4.1.5
01
Field Name
ADDITIONALDATA5
Debit Cards
P2P Encryption
Transaction Response—
String (22 Characters): 7digit Key ID + {1,2} +
MMddyyyyHHmmss
EBT
Stored Value
Cards Fleet Cards
P2P Encryption
Transaction
Response—String (22
Characters): 7-digit
Key ID + {1,2} +
MMddyyyyHHmmss
P2P Encryption
Transaction
Response—String (22
Characters): 7-digit
Key ID + {1,2} +
MMddyyyyHHmmss
P2P Encryption
Transaction
Response—String
(22 Characters): 7digit Key ID + {1,2} +
MMddyyyyHHmmss
Current Balance Current Balance ADDITIONALAMOUNT For Debit Transactions it will contain the surcharge for the transaction, if one has been setup on the
Host. (If surcharge applies, it must be printed on the customer receipt).
Applicable to Paymentech only.
CASHBACK_AMOUNT Cash Back Amount
ADDITIONALAMOUNT For Debit Transactions it will contain the surcharge for the transaction, if one has been setup on the
Host. (If surcharge applies, it must be printed on the customer receipt).
Applicable to Paymentech only.
Current Balance Current Balance
CHECK
Object CARD Object
ADDITIONAL
INFO
00
ACH
No Check
Verification—
(default value)
Credit Card
No credit card account verification, default value.
Applicable only when adding a new Account to the
SecureNet Vault.
EBT
MERCHANT_KEY
Object Reference
Gateway
Extended
Services
Supported Platform:
Paymentech
Ceridian
ACH
Refer:
02
Check verification through
Certegy
Pre-Note with
ACH Provider
Credit card account verification. Applicable only when adding a new Account to the SecureNet Vault.
Update EXPDATE of credit card during Process
Transaction by Customer ID.
78
SecureNet Gateway Implementation Guide 4.1.5
Variable Text
CHECK
Object CARD Object
11 (EBT indicator) + 15character long leftjustified space-filled
EBT Voucher number.
For EBT Voucher Clear transactions only.
MERCHANT_KEY
Object
For EBT transactions only. 11 (EBT indicator) + 7-digit FNS number (left-justified, space-filled, if FNS is less than 7 digits).
Reference d. TRANSACTION_SERVICE
[Regular Transactions]
0 —Regular Transaction (Default)
[SecureNet Vault Transactions]
1 - Process Transaction using Customer ID
2 - Process Transaction using SECONDARY_MERCHANT_KEY
3 - Process Transaction Add Customer and Account
G. Commodity Code for Level III items
Summary and Item Commodity code and Description fields should be populated with Standard United Nations Standard
Products and Services Code(UNSPC) from unspsc.org
Standard codes can be found at http://www.unspsc.org/Search.asp
a. Unit of Measurement for Level III items
2 characters UOM should be submitted for Item Unit type for Level III transactions. Refer ANSI X-12 Allowable
Units of Measure and Codes
Standard codes can be found at http://das.ct.gov/Purchase/Info/ANSI_UNITS_OF_MEASURE.pdf
2 characters HealthCare Code is required for HealthCare Transactions.
Refer United States Health Information Knowledgebase(USHIK) Metadata Registry for Accredited Standards
Committee X12 Service Type Code.
Standard Service Type code can be found at http://ushik.ahrq.gov/ViewItemDetails?system=mdr&itemKey=27573000 c. Product Codes for Petroleum Industry Transactions
Paymentech Petroleum Product Codes/Paymentech ‘Generic’ Codes
Ethan1 (Regular) 001 Wipers 023
Super Unleaded
Other Fuel
Unleaded Plus
Gas/Alcohol 2
004
005
006
008
Tires
Hoses
Filters
Oil Change
026
027
028
030
031
79
SecureNet Gateway Implementation Guide 4.1.5
Diesel 2 009 Tune Up 032
Unleaded 10% blend
Unleaded Plus 10% blend
Super Unleaded 10%
Unleaded 7% blend
Unleaded Plus 7%
Super Unleaded 7% blend
Refer Fuel
Farm Fuel
012
013
014
015
016
017
018
019
Tires/Batteries/Access
Other
Accessories
Food
Service
Parts
Labor
Reserved
035
040
041
042
043
044
045
046
Motor Oil 021 Sales Tax**
Lamps 022
056
*Product Code 051: Discount is a negative amount
**If tax is submitted as a Product Code, it must ALSO be submitted in the purchasing card data fields.
Product Amounts can be treated as negative values if they have been setup as such with the host. When submitted, the total of the positive product amounts minus the negative product amounts must equal the transaction amount. Transaction amounts must cross foot:
Sum of all Product Amounts must equal Transaction Amount.
If provided: Unit Price * Quantity = Product Amount (Quantity multiplied by Unit Price is rounded using 4/5 rounding to derive the extended amount.)
80
SecureNet Gateway Implementation Guide 4.1.5
APPENDIX B: DEVELOPER NOTES
Some best practices for SecureNet API implementation.
A. Gateway URL, SecureNet ID, SecureKey and test mode should be designed to be configurable by the developer who is integrating to the API
B. Using WSDL to process test and certification transactions
The below steps/considerations must be followed to add the correct WSDL to the project in order to test and certify the application:
1. The certify (test) WSDL is located in this URL: https://certify.securenet.com/api/gateway.svc
2. If Visual Studio is used, the WSDL reference will be added only as HTTP, not as HTTPS. This will cause a problem when trying to send transactions to the Gateway (live/production) environment using the same configuration.
3. Manually change all the references from HTTP to HTTPS in the code before running any test transactions
4. After adding reference in project, please use the end points below to run transactions:
SOAP: (XML Web service) b. For XML Post: https://certify.securenet.com/API/Gateway.svc/webhttp (XML post)
C. Using WSDL to process live/production transactions
The below steps/considerations must be followed to add the correct WSDL to the project in order to process live/production transactions once the application has been fully tested and certified by SecureNet:
1. Do not re-add any reference using a production URL— https://certify.securenet.com/api/gateway.svc
2. After adding reference in project, please use the end points below to run live/production transactions:
SOAP: (XML Web service) b. For XML Post: https://gateway.securenet.com/API/Gateway.svc/webhttp (XML post)
3. While building a SOAP message, if wsdl is getting downloaded from certify and processing each transaction on production URL then it could cause issue if Demo is down or there is some mismatch between demo wsdl and production wsdl.
D. Order ID Implementation
Pre-generate the unique OrderID and store it before it is submitted to the Gateway. In case of failure due to time out, non-receipt of response from the Gateway or unfinished transaction the original transaction can be retrieved by using the DCI or the transaction lookup method. Order ID will be matched only with approved transactions, the
OrderID can be resubmitted for declined or error transactions. Order ID will only be valid for a period of 30 days.
Business rules for Response Handling should be written based on Response Code and should not be based on
Response Text. In case of Response Code 3, the Gateway does not have any record of the transaction.
F. Handling Transaction Time out
Applications should be designed to handle time out scenarios; in case of non-receipt of transaction response within the set application timeout period. Please consider the steps below:
Set the transaction timeout for the application to 30 seconds
Always send the same Order ID if a time out occurs or you are trying the same transaction again
81
SecureNet Gateway Implementation Guide 4.1.5
Use unique Order ID across system
Don’t re-attempt the timed out transaction for at least 60 seconds
If a response code -3 and response reason code “01O2” (for unique order id) is received, retrieve the original transaction response detail from the Gateway using extended API—“Get Transaction by OrderID”
DCI “Duplicate Transaction Indicator” can be very helpful to handle time outs, please consider the steps below:
Send DCI=2 on retried transaction if original transaction time’s out and predefine the settings in Virtual terminal, make sure to send all values as per setting.
If retried transaction already exists as per the settings, the return response code will be “1” as approved and response reason code will be “DCT02”
DCT02 is indicator of existing transaction from the Gateway only (customer is not charged twice)
DCI indicator is not recommended if the business allows having same amount and same card for multiple transactions by same customer.
Do not submit DCI for every transaction, submit DCI only in case of suspected duplicate or In case of failure due to time out, non-receipt of response from the Gateway
Time out for SecureNet Vault Accounts:
CSDI and ACDI must be utilized to handle time out while performing SecureNet Vault functionality
CSDI “Customer Duplicate Indicator” - CSDI=1 is recommended value; this will not add same customer again if customer is already exists.
ACDI “Account Duplicate Indicator” - ACDI=1 is recommended value; this will not add same payment again if payment account already exists/associated with the customer record/customer ID.
When merchant has turned on AVS and CVV based fraud settings, the transaction will be declined by the Gateway though it might be approved by the card issuer.
The Global XSD should be housed locally under the developer’s end point and should be updated only if required.
As part of the integration the XSD should be downloaded to a local file system of the application and configured to be utilized by the application from the local path. The XSD should not be validated against the online version to increase performance and reduce errors. During each change to the system, download the latest XSD to be utilized by the application.
I. Fault exceptions
When submitting an incorrect request, which is not validated by the XSD, an “HTTP 400 Bad Request” response will be sent. Look at the RESPONSE_REASON_TEXT for description of the error and modify the request accordingly.
When submitting an HTTP POST (REST) request:
Please make sure that all the request elements are present in the order that is defined in XSD.
Fields, which are of value type, i.e. Integer, Decimal, etc., must be present in the request even if not needed, if their parent object is present.
For example: If TRANSACTION object is sent as request xml then OVERRIDE_FROM,
TOTAL_INSTALLMENTCOUNT, INSTALLMENT_SEQUENCENUM, TRANSACTION_SERVICE,
RETAIL_LANENUM, DCI, AMOUNT, CASHBACK_AMOUNT elements should be present in proper order (as defined in XSD) even if the values are 0.
82
SecureNet Gateway Implementation Guide 4.1.5
Transaction retry process timeouts, General Error Handling, response codes for retry
Order ID is required.
Make configurable parameters for key API elements
At the minimum Endpoint URL, SecureNet ID, SecureKey, Test Flag are required fields.
XSD implementation—copy locally and implement validation
The full SecureNet Vault Layout is required if processing a Vault transaction.
SecureNet AutoBill Layout
J. Point to Point Encryption (P2PE)
Hardware-based encryption:
SecureNet Gateway supports encrypted IDTech MSRs.
The MSRs have to be ordered with IDTech through SecureNet.
The Injected Keys for the test and production are not the same; keep this in mind when ordering the devices and be sure to specify what environment the device will be used in.
Software-based encryption:
Make sure to rotate keys at the time of expiration
Always keep both primary and secondary key active
Do not create 2 keys within a 2 day period and without proper validation (2 keys cannot be created within a
24 hour time period)
Make sure to process all transactions before a new key is created.
Check P2P key expiration date in the transaction response field. Create the new key as soon as primary key is expired
Prevent non encrypted data from being resident in memory on the device executing the encryption software once the data is encrypted.
Make sure PCI guidelines are followed.
Refer to the “Gateway API P2PE Implementation Guide” for details on implementation
83
SecureNet Gateway Implementation Guide 4.1.5
K. Response Handling Chart
L. Tokenization
SecureNet Vault Customer and Payment Account Data Structure Examples
Payment Account
Customer
Payment Account
SecureNet ID
Customer
Payment Account
Payment Account
Payment Account
Customer Payment Account
A token for an associated payment account is represent by combination customer ID and payment ID if the multiple forms of payment are stored per customer.
84
SecureNet Gateway Implementation Guide 4.1.5
AutoBill / SecureNet Vault Customer / Payment Account and Schedule Data Structure Examples
AutoBill Schedule Payment Account
Customer
Payment Account
Payment Account
AutoBill Schedule AutoBill Schedule
SecureNet ID Customer Payment Account
AutoBill Schedule
Payment Account
AutoBill Schedule
Customer Payment Account
M. Test Data
To perform tests in our test environment make sure to set Virtual Terminal to ‘LIVE MODE’, the ‘TEST’ parameter as ‘FALSE’, and send the transactions to https://certify.securenet.com/API/Gateway.svc
To request a test account, please download and complete the “Integration & Certification Test Account Request
Form” from the API Resource page: http://www.securenet.com/Partnership/Developers/APIResourceCenter.aspx
Test Credit Card Numbers for Approved Transactions
American Express 370000000000002
Discover 6011000000000012
MasterCard 5424000000000015
Visa 4444333322221111
Fraud Prevention Settings:
AVS Match
CVV/CID Approval
CVV/CID Visa
CVV/CID MasterCard
20008
568
998
Test Credit Card Numbers for Declined Transactions:
MasterCard 5105105105105100
MasterCard 5555555555554444
Visa 4111111111111111
Visa 4012888888881881
American Express 378282246310005
American Express 371449635398431
Checks:
For checking account numberuse any 6-digit number
Valid Routing Numbers: 222371863
307075259
052000113
85
SecureNet Gateway Implementation Guide 4.1.5
Note: a full test scenario script is available upon request. Please contact [email protected]
for assistance .
Contact SecureNet certification team/analyst for basic code sample for API implementation. Please note that the sample is for reference only to be utilized for application development. i. API Error Codes
Gateway API can return multiple errors for different operations. Refer to the Error Codes Reference Guide document for a complete list (available upon request). ii. How to Contact Technical Support
For problems with transaction processing or connection problems to the server, contact SecureNet
Technical Support at [email protected]
or (888) 231-0060, option 3. Note that the SecureNet ID will be necessary and sample code might need to be provided to further research questions/problems.
NOTE: API Support is available between the hours of 9am and 6pm Monday through Friday.
iii. Certification Request Form
If a Certification Request Form is required, contact [email protected]
to request one. a. Storing and Protecting Data Beyond Authorization
Table 35 (along with information obtained from the PCI Data Security Standard, version 1.2) illustrates data elements commonly used for credit/debit card processing and the rules for storing and protecting these fields for use beyond the original authorization.
Guidelines for Storing and Protecting Sensitive Data
Cardholder Data
Data Element
Primary Account Number (PAN)*
Storage Permitted Protection Required
Yes Yes
Sensitive Authentication
Data****
Full Magnetic Stripe***
CVD (CVC2/CVV2/CID)
PIN/PIN Block
No
No
No
* The PAN (at a minimum) must be rendered unreadable anywhere it is stored.
** These data elements must be protected if stored in conjunction with the PAN.
*** Includes full track data from magnetic stripe, magnetic stripe image from the chip, or elsewhere.
**** Sensitive Authentication Data must not be stored after the authorization (even if encrypted).
For PCI-DSS and Payment Application Data Security Standard (PA-DSS) standards: https://www.pcisecuritystandards.org/
N/A
N/A
N/A
86
SecureNet Gateway Implementation Guide 4.1.5
This chapter covers general rules that apply to credit card processing. a. Magnetic Stripe, Encrypted PIN, and CVD Retention
In accordance to the PCI Compliance Guidelines, it is strictly prohibited by to maintain the contents of a magnetic stripe or other cardholder verification information (such as the encrypted PIN or CVD) for future processing. Examples of this would be a recurring billing type transaction (such as monthly membership fees) or an additional authorization obtained at a hotel for an extended stay. You can store the account number and expiration date and send these types of recurring transactions for authorization as manually entered. To lower the potential for fraud, it is recommended to never store a magnetic stripe read after authorization is completed.
All certifications require that track and encrypted PIN data no longer be stored and submitted for specific card types following the initial authorization. For these card types, only the account number and expiration date should be delivered within any reversal advice requests or AFD completions.
See above, PCI Compliance, for detailed information relating to data retention guidelines.
P. Basic Card Verification Data
Visa and MasterCard implemented Card Verification Values (CVV) and Card Verification Codes (CVC2) to combat fraud. These values are the result of an algorithm and are encoded on the magnetic stripe of the card. Any alteration of the data elements read from the magnetic stripe prior to sending for authorization will cause the value not to match when the issuer reruns the algorithm at authorization time.
Refer to TRACKDATA details in Appendix A. a.
Enhanced Card Verification Data
The associations have implemented an enhanced security program that assists a merchant in the card-notpresent environment to verify that the cardholder has possession of the card. Gateway refers to the data that is supported in this enhanced security program as CARDCODE.
Card Verification Programs
Card Type
Visa
MasterCard
Program Name Length of Value
Enhanced Card
Verification Value (CVV2)
3
Enhanced Card Verification Code (CVC2) 3
American Express Card Identifier (CID)
Discover
Stored Value
Card Identifier (CID)
Enhanced Card
Verification Value (CVD2)
4
3
4
Card Placement
Back of card, next to account number on signature panel
Back of card, next to account number on signature panel
Front of card, above on right of account number
Back of card, next to account number on signature panel
Back of card, typically hidden under scratch off panel
This information used is to determine whether or not a consumer is in possession of the physical card in a nonface-to-face environment. Although Gateway supports a CARDCODE on transactions that are both swiped and manually entered, most associations and issuers do not validate the CARDCODE when the card was swiped.
When this happens, there will not be a response code in the transaction response.
Although Enhanced Card Verification Data is considered optional, for additional fraud protection, include this data in all manually keyed, card-not-present authorization requests.
87
SecureNet Gateway Implementation Guide 4.1.5
The Gift Card program normally verifies the CARDCODE on manually entered redemptions, redemption authonly, and balance inquiry transactions.
The CARDCODE response can be used by the merchant to determine if the cardholder has possession of the card at the time of the sale. By using the CARDCODE response code to determine the legitimacy of the transaction, the merchant can reduce the potential of fraudulent transactions being processed, therefore reducing the merchants chargeback losses.
CARDCODE information does not impact interchange assessments.
See Appendix A, for a full listing of the CARDCODE response codes.
Q. Address Verification Service
Address Verification Service (AVS) provides merchants with additional information concerning the authentication of a particular transaction. Supporting AVS has several benefits for the merchant:
Requesting to have the cardholder’s address verified allows the merchant better fraud protection when the cardholder is not physically present.
Requesting AVS may help to prevent chargebacks if the merchant can identify a fraudulent transaction prior to completing the sale/transaction.
When processing transactions in the MOTO/Card Not Present/Direct Marketing industry or Electronic
Commerce industry, Visa will assess a lower interchange rate if AVS is requested. (A match is not required.)
When processing transactions in the Retail environment, merchants that must manually key an account number due to a bad magnetic stripe will receive a lower interchange rate if they request (and receive) verification of the cardholder’s zip code. (A match is required.)
AVS is provided by Visa, MasterCard, American Express, and Discover Cards. PO Box addresses are accepted if it is the cardholder’s billing address.
See Appendix A for a full listing of AVS response code values by card type.
AVS-only requests are supported in Gateway to certain processors. When requesting address verification only, the transaction amount must equal $0.00 and has to be submitted as a verification transaction.
Both Visa and MasterCard offer businesses with a card platform that provides them with additional reporting so that the business can monitor their user activity on those cards. All of these cards fall under the umbrella term of
Commercial Cards . The individual products are: a. Corporate, Business, and Purchase
In order to provide this reporting to these businesses, merchants must submit additional data with each transaction. If submitted with the transaction, the merchant qualifies for lower consumer card interchange rates.
If not submitted, both Visa and MasterCard assess higher Commercial interchange rates based on if the card was swiped or keyed, timeliness of the deposit, and so on. i. Required Data Elements
Commercial Card data is required only at the time of settlement. Gateway Response includes indicator to specify if the card is Level II or Level III Valid. Merchant should be enabled to submit Level III data. If the transaction was submitted without any Level II or Level III data during the initial authorization the data can be updated before settlement using possible 2 methods.
88
SecureNet Gateway Implementation Guide 4.1.5
If the transaction was submitted as AUTH_ONLY, the qualification data can be submitted during the
PRIOR_AUTH_CAPTURE transaction.
If the transaction was submitted as AUTH_CAPTURE or PRIOR_AUTH_CAPTURE, UPDATE transaction can be submitted with the qualification data before settlement occurs.
Gateway supports both Level II and Level III data requirements as defined by Visa and MasterCard with certified processors only.
When processing Level III data, Level II data is required as well.
Merchant must mask all of the cardholder’s account number (referred to as Account Truncation) except for the last four digits, and the expiration date must be masked in its entirety. This applies to:
Both merchant and cardholder printed receipts
Printed and displayed transaction reports
Displayed transaction information
In addition, the merchant number or SecureNet ID must not be printed on the receipt.
Best practice would be to generate receipts in this manner whether online or printed.
Mask all of the cardholder’s account number (referred to as Account Truncation) except for the last four digits.
This must be done by using either asterisk (*) or an X.
For example: ************1234 or XXXXXXXXXXXX1234
The same practice applies to ACH transactions also.
SecureNet recommendation that the cardholder's account number be masked and the expiration date is suppressed on ALL credit card receipts, regardless of the card type.
Visa, MasterCard, and Discover require that merchants indicate when a transaction is being processed on a recurring basis. All Recurring Transactions must be submitted to the host as Mail Order Transactions and the
MOTO Indicator must equal 02. d. Electronic Commerce Processing Rules
Electronic Commerce environments are classified as those environments where the card and/or cardholder are not physically present at the time of purchase and the transactions are performed over the Internet. An ecommerce Web site accepting credit card payments for purchases made on their Web site would be an example.
Cardholders can only be billed for items actually shipped. If an item ordered turns out to be not in stock, the settled transaction should only be for the amount of the items shipped.
In order to obtain the best interchange rate for Electronic Commerce transactions, the following is required:
Perform Auth_Only Transactions and capture when the item is shipped
The transaction must be settled within 48 hours
Industry-Specific Data must be present in all transactions
89
SecureNet Gateway Implementation Guide 4.1.5
The transaction amount must match the final authorized amount. Amount tolerance between authorization and clearing is 0%. (Partial void should be utilized to match the authorization and settlement amount
The transaction date must match the ship date and must be no later than 7 days after the authorization date
Address Verification (AVS) must be requested. A match is not required e. Restaurant Processing Rules
In order to obtain the best interchange rate for Restaurant transactions, the following is required:
The transaction must be settled within 24 hours
Industry-Specific Data must be present in all transactions
The settled transaction amount must be within 20% of the authorized amount. The initial authorization/sale must be submitted for the actual transaction amount. It must not be altered to include an additional percentage that accounts for a tip being added before settlement
If the transaction must be manually keyed, AVS must be requested. A match of the zip code is required
Cardholder signature is required
Tip Adjustment:
Transactions has to be submitted as AUTH_ONLY transaction, the tip should be included in the
PRIOR_AUTH_CAPTURE before the batch close and should be added to the original sale amount in addition to the Tip Amount Field.
Tip re-adjustment can be done using the PRIOR_AUTH_CAPTURE before the batch is closed on the
Gateway.
S. Batch Release Options
The Gateway will close the current open batch at a designated time each day.
This means that there is no end of day batch processing required from the merchant. Merchant is setup to auto close on the Gateway by default and has the ability to setup the close time based on their business needs.
NOTE: Verify with the merchant support and processor for the best cut off time to receive timely funding for the transactions
Merchants with high volume of transactions should prefer to use the auto close option.
Multiple Batches might be created based upon the processor, For Example ACH would always be a separate batch or Stored Value will be a separate batch. b. Manual Batch Close
The software provider can implement a function called a Batch Close using Transaction Services thus giving the merchant the flexibility to close the current open batch at any time throughout the day or perform multiple
Batch Releases.
Also manual batch close can be performed on the Virtual Terminal using unsettled transactions report.
90
SecureNet Gateway Implementation Guide 4.1.5
Batch Inquiry functionality using Extended Services allows the POS to receive transaction details (all transactions or by card type) or card type totals (all card types or a specific card type) for a particular Batch ID.
NOTE: Manual Batch Release and Batch Inquiry is not recommended for merchant having more than 1000 transactions per day.
91
SecureNet Gateway Implementation Guide 4.1.5
APPENDIX C: REFERENCES
A. Introduction
The Valutec WS is a standard web service as defined by World Wide Web Consortium (W3C, http://www.w3.org).
It provides several methods that the programs and web applications can use to process transactions, provide reports, and update customer information on Valutec gift and loyalty cards.
If not familiar with web services, examine the following resources:
For an overview of web services and related technology: http://en.wikipedia.org/wiki/Web_service
For an introduction to XML, the foundation for both SOAP & WSDL: http://www.w3schools.com/xml/default.asp
For a tutorial on SOAP, the communication language of web services: http://www.w3schools.com/soap/default.asp
For a tutorial on WSDL, the language that web services use: http://www.w3schools.com/wsdl/default.asp a. Automatic Discovery and Code Generation
The code documents itself in a form that is machine readable, using WSDL. You can obtain the WSDL definition of this web service with the links provided for the appropriate service.
Many Java and .NET development environments include or have available tools that can read this WSDL and automatically generate a set of classes that encapsulate all the details of interacting with the web service. You can then use the web service via these wrapper classes without needing to deal with any of the WSDL, SOAP, HTTP, or network communications details. After the wrapper classes have been generated, the only code that needs to be written is to instantiate the wrapper and call the approprithete transaction method on it. Only 1 or 2 lines of code will be required to be written (thanks to the hundreds of lines that were already automatically generated).
If these web services tools are available, there only two things that need to be known in order to start using this web service:
1. How to use web service tools
2. The WSDL URL for this web service
NOTE: The names of some web methods may be modified by existing tools in order to follow naming conventions or avoid the illegal use of keywords in the programming language. For example, in Java and other languages the void(...) web method may be renamed to _void(...) or some other variation because void is a language keyword.
If these web services tools are not available, then use one of the other options:
If comfortable with SOAP, use the SOAP 1.1 or SOAP 1.2 interfaces. The documentation for each web method (links provided below) contains sample SOAP 1.1 and 1.2 request/response pairs. Note that each sample shows the entire HTTP/S message including header fields and content.
― Production SOAP URLs
https://gateway.securenet.com/API/Gateway.svc/soap , for Transaction API (Gateway services)
https://gateway.securenet.com/API/data/service.svc/soap , Extended Transaction Functionality
API (Extended services)
https://gateway.securenet.com/API/data/transaction.svc/soap , for Extended Transaction
Process API (Transaction services)
92
SecureNet Gateway Implementation Guide 4.1.5
― Certification SOAP URLs
https://certify.securenet.com/API/Gateway.svc/soap , for Transaction API (Gateway services)
https://certify.securenet.com/API/data/service.svc/soap , for Extended Transaction Functionality
API (Extended services)
https://certify.securenet.com/API/data/transaction.svc/soap , for Extended Transaction Process
API (Transaction services)
Use the HTTP GET interfaces. Sample request/response pairs for this interface are provided with the documentation for each web method. Note that each sample shows the entire HTTP/S message including header fields and content.
If not using tool-generated wrappers, be familiar and comfortable with the libraries for raw TCP/IP and/or
HTTPS communication.
93
SecureNet Gateway Implementation Guide 4.1.5
Revision History
Date Version Revision Description of change(s) Author(s)
12/23/2011 4.1.2
01/11/2012 4.1.2
01/11/2012 4.1.2
01/11/2012 4.1.2
01/11/2012 4.1.2
01/27/2012
5/03/2012
4.1.2
4.1.3
6/21/2012 4.1.3
08/20/2012 4.1.4
08/20/2012 4.1.4
1 Initial
2 Added
2 Added
2 Added
8/22/2012 4.1.4
9/14/2012 4.1.4
4 Formatted/edited new additions. Added Proprietary and
Confidential to cover and footer, updated TOC and version.
4 Revised and updated Hotel Sale Code, Charge Type and
Auto Sale Code. Fixed bookmarked links.
11/27/2012 4.1.4 5 Rearranged per Judi. Narendra updated / revised items identified by Judi.
12/12/12 4.1.5 1 Added
Added ProcessABAccount method in Secion4.3
Added GetABAccount_Ext & GetABAccounts_Ext (overload methods) in Section 4.4
12/31/12 4.1.5 1 Complete
Preetham Gowda, Jorge
Tardio, Narendra Solanki
Narendra Solanki
Narendra Solanki
Narendra Solanki
2 Added Solanki
2 Modified verbiage for REF_TRANSID in Appendix Jorge Tardio, Narendra
Solanki
3 Added to Sections: 8.20.2, 8.20.3 and 8.21.1.1
Added to Appendix A, Section C
Added to Appendix B, Section C
Mukesh Agrawal
3 Revised Section 4.5—Reporting Methods for SecureNet
Vault and AutoBill Services [Extended Services],
GetABAccounts—Method to retrieve all AutoBill accounts of
CustomerID
4 Updated CARDLEVEL_RESULTS values in Appendix A for
MasterCard
4 Revised CARDLEVEL_RESULTS values in Appendix A for
MasterCard
Narendra Solanki
Kathiravan Srinivasan
Narendra Solanki
Cindy Magee
Stella Wateba / Cindy
Magee
Judi / Narendra / Cindy
Narendra Solanki
Preetham Gowda / Stella
Wateba / Judi Seguy
94
Unduh
Tautan publik diperbarui
Tautan publik ke obrolan Anda telah diperbarui. You may view and manage your chat links after registration here.
Tautan publik dokumen
Iklan
