This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
4.6.1.3.1. Swiped Credit Sale with Purchase Card Level III Data ........................................... 86 4.6.1.3.2. Swiped Credit Sale Fuel Transaction ................................................................... 87 4.6.1.3.3. Swiped Fleet Sale .............................................................................................. 88 4.6.1.3.4. Manually Entered Fleet Sale ............................................................................... 89
4.24.5.1. Gift ForceAuth Transactions .................................................................................. 137 4.24.5.2. Examples .............................................................................................................. 137
4.24.5.2.1. Swiped Gift Force ........................................................................................... 137 4.24.5.2.2. Manual Gift Force (ForceAuth Redeem) ........................................................... 138 4.24.5.2.3. Manual Gift Force (ForceAuth Reload) ............................................................. 138
4.25.4.2. Examples .............................................................................................................. 144 4.25.4.2.1. Credit Sale with DCC ....................................................................................... 144 4.25.4.2.2. Credit Sale with MCP ...................................................................................... 145
This document assists Point‐of‐Sale (POS) developers in integrating directly with BridgePay’s PathwayLINK Payment Gateway using the following integration methods:
.NET Web services HTTPS POST SOAP
1.2. Testing
A test or live merchant account with BridgePay is necessary to successfully process transactions. To acquire a test account, contact the BridgePay Developer Support Department at [email protected] or fill out the test account request form at http://www.bridgepaynetwork.com/testAccount.php.
You may use the following cards in testing:
Card Type Number MasterCard 5439750001500347
Visa 4005550000000019
Discover 60011111111111117
Diners 36999999999999
AMEX 374255312721002
If you implement swiped, card‐present transactions (Credit, Debit, EBT, Gift Cards), please send a request to [email protected], and we will ship a set of test cards to you.
1.2.1. Testing for PIN-based Transactions
Personal identification number (PIN)‐based debit testing requires an encryption scheme‐injected PIN pad by a specific processor and either a physical live or test card to run transactions.
1.2.2. Duplicate Transaction Handling
BridgePay highly recommends that all integrators take duplicate transactions into consideration when performing PathwayLINK integration.
10
A duplicate transaction is a transaction with the same card number, expiration date, amount, and date of a previously processed transaction. At the merchant’s preference, BridgePay can enable or disable a gateway‐level option called Force Duplicates. BridgePay strongly encourages all merchant accounts enable the Force Duplicates option. If a merchant account enables Force Duplicates and a duplicate transaction occurs, the response returned contains a duplicate transaction message. Sample Response <?xml version="1.0" encoding="utf-8" ?> <Response xmlns:xsd=http://www.w3.org/2001/XMLSchema”
</Response> The duplicate transaction response returns a Result of 110, a RespMSG and Message of Duplicate Transaction, and HostCode property containing the PNRef of the original transaction. You can set the Force property within the ExtData field to T to force duplicate transaction processing, regardless of merchant account settings. This method of overriding individual transactions helps eliminate accidental duplicates (i.e., double charges) while still processing valid duplicates on a case‐by‐case basis.
11
Chapter 2. Web Service Functionality
PathwayLINK makes a test and documentation .asmx page available to integrators:
This page contains online documentation and a testing form for each operation. During integration, it may be helpful to process sample transactions using the test forms to get a feel of how the various operations work or to troubleshoot integration problems.
The following Transaction Processing Operations are currently supported by PathwayLINK:
GetInfo – Retrieves information from the Web service. ProcessCheck – Processes check transactions for a merchant. ProcessCreditCard – Processes credit card transactions for a merchant. ProcessDebitCard – Processes debit card transactions for a merchant. ProcessEBTCard – Processes EBT card transactions for a merchant. ProcessGiftCard – Processes gift card transactions for a merchant ProcessLoyaltyCard – Processes loyalty cards for a merchant. ProcessSignature – Sends a signature to apply to a receipt transaction.
2.1. GetInfo
This Web service operation retrieves information pertaining to the transaction type (TransType) specified. The URL to access this operation is:
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter Description UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of GetInfo transaction. Valid values are:
BatchInquiry: Returns a comma‐delimited list containing the summarized transaction dollar amount and transaction count for each payment method in the current batch. The list takes the format: Payment_Type_Amount=X.XX,Payment_Type_Count=X.
Setup: Returns a comma‐delimited list containing merchant setup information. The list takes the format: Setup_Name1=Y|N,
12
Parameter Description Setup_Name2=Y|N.
StatusCheck: Returns OK if PathwayLINK makes a successful connection to the payment server with the supplied username and password; otherwise, an error message is returned.
Initialize: Returns the merchant account setup information (e.g., Partner Number, Merchant ID, credit card type, etc.).
ExtData Optional. Extended data in XML format. Valid values are:
<TrainingMode>Mode</TrainingMode> Enables/disables training mode. Valid values are: T, F.
2.1.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.1.1.1. BatchInquiry
The following example retrieves information pertaining to the BatchInquiry TransType. After listing the dollar amount and transaction count for each TransType of a payment type, there is a net count and net amount for that tender type.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter Description UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the check transaction. Valid values are:
Sale: Makes a purchase with a check.
Auth: Authorizes/verifies the amount of a check.
Return: Returns the money of a settled check transaction to the check holder.
Void: Cancels an unsettled check transaction.
Force: Forces a previous sale transaction into the current batch (ForceSale).
Capture: Settles a single transaction in the current batch. Only for terminal‐based processors.
CaptureAll: Settles all transactions in the current batch. Only for terminal‐based processors.
CheckNum Required for all TransTypes but Void, Capture, and CaptureAll. Check number that uniquely identifies each individual check.
TransitNum Required for all TransTypes but Void, Capture, and CaptureAll. The transit number uniquely identifies a bank.
AccountNum Required for all TransTypes but Void, Capture, and CaptureAll. The account number uniquely identifies a check holder’s bank account.
Amount Required for all TransTypes but Void, Capture, and CaptureAll. The total transaction amount in DDDD.CC format.
MICR Optional. The Magnetic Ink Check Recognition data line, which includes TransitNum and AccountNum. Required for processing check‐present transactions. The format of the MICR is processor‐specific. If you are unsure about what format your check processor accepts, pass the RAW MICR as well in the TOAD format.
NameOnCheck Required for all TransTypes but Void, Capture, and CaptureAll. The check holder’s name as it appears on the check. The parameter may be required, depending on the merchant’s processor setup. This parameter removes invalid characters. See XML Character Removal on page 172 for more details.
16
Parameter Description
DL Optional. The check holder’s driver’s license number. This parameter
removes invalid characters. See XML Character Removal on page 172
for more details.
SS Optional. The check holder’s Social Security Number. This parameter
removes invalid characters. See XML Character Removal on page 172
for more details.
DOB Optional. The check holder’s date of birth. This parameter removes
invalid characters. See XML Character Removal on page 172 for more
details.
StateCode Optional. The check holder’s 2‐character state code. The parameter
may be required depending on the merchant’s processor setup. This
parameter removes invalid characters See XML Character Removal on
page 172 for more details.
CheckType Optional. The type of the check. Valid values are: Personal, Corporate,
Government.
ExtData Optional unless otherwise noted below or in the Processor Addendum
on page 78. Extended data in XML format. Valid values are:
<TimeOut>Timeout</TimeOut> Timeout value in seconds. The
default value is 30.
<PNRef>PNRef</PNRef> Reference number assigned by the
payment server. Required for Return, Void, Force, and Capture
transactions.
<Phone>Phone</Phone> Phone number. The data within this XML
tag parameter removes invalid characters. See XML Character
Removal on page 172 for more details.
<EMail>Email</EMail> Email address. The data within this XML tag
parameter removes invalid characters. See XML Character Removal
on page 172 for more details.
<RawMICR>RawMICR</RawMICR> Magnetic Ink Check Reader
data from the check reader in the format of
TransitNumTAccountNumOCheckNum. Required for check‐present
transactions.
The TOAD format is the accepted default format for Raw
MICR for all check processors.
<InvNum>Num</InvNum> Invoice tracking number. The data
within this XML tag parameter removes invalid characters. See XML
Character Removal on page 172 for more details.
<TrainingMode>Mode</TrainingMode> Enables/disables Training
Mode. Valid values are: T, F.
17
Parameter
Description
<AllianceNum>AllianceNum</AllianceNum> Alliance number for
the check.
<AccType>AccType</AccType> Bank account type for the check.
Valid values are: Checking or Saving.
<CityOfAccount>City</CityOfAccount> City of the check holder's
residential address. The data within this XML tag parameter
removes invalid characters. See XML Character Removal on page
172 for more details.
<BillToStreet>Street</BillToStreet> Street of the check holder's
billing address. The data within this XML tag parameter removes
invalid characters. See XML Character Removal on page 172 for
more details.
<BillToCity>City</BillToCity> City of check holder's billing address.
The data within this XML tag parameter removes invalid characters.
See XML Character Removal on page 172 for more details.
<BillToState>State</BillToState> Two‐character state code of the
check holder's billing address. The data within this XML tag
parameter removes invalid characters. See XML Character Removal
on page 172 for more details.
<BillToPostalCode>Code</BillToPostalCode> ZIP code of the check
holder's billing address. The data within this XML tag parameter
removes invalid characters. See XML Character Removal on page
172 for more details.
<BillToCountry>Country</BillToCountry> Country of the check
holder's billing address. The data within this XML tag parameter
removes invalid characters. See XML Character Removal on page
172 for more details.
<CustomerID>ID</CustomerID> Customer ID. The data within this
XML tag parameter removes invalid characters. See XML Character
Removal on page 172 for more details.
<DebugData> Simulates scensarios for QA. Available in Debug
Standard Transaction (e.g., Sale): Exception thrown prior to
final database write. QA/Debug.
Auto‐Reversal: status of void/reversal returned to user. QA.
Capture: In a multi‐segment batch, the second segment fails.
QA/Regression.
<SerializeProcessorHandler2Data>T</SerializeProcessorHandle r2Data> Serializes the objects associated with the Process and ProcessSettle interface methods via Log4Net. Informational.
18
Parameter Description Valid values are: T, F.
<ForceAdjustmentTransactionFailure>T</ForceAdjustmentTran sactionFailure> Generates an Adjustment transaction exception before the final adjustment of the original record. Simulates cloned records but does not adjust the original transaction. QA/Debug. Valid values are: T, F.
</DebugData>
2.2.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.2.1.1. Manual Check Sale
The following example processes a manually entered check Sale transaction.
The following example processes a swiped check Sale transaction. Because a swiped check sale is a check‐present transaction, the ExtData parameter includes the RawMICR data.
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="https://gateway.itstgate.com/SmartPayments/"> <Result>0</Result> <RespMSG>Approved</RespMSG> <Message>APPROVAL</Message> <AuthCode>AUTH NUM 121-704</AuthCode> <PNRef>11622</PNRef>
</Response>
2.2.1.3. Manual Check Return
The following example processes a manually entered check Return transaction. Because this is a return transaction, the PNRef element is present within the ExtData parameter.
The following example processes a check Void transaction. Because this is a void transaction, the PNRef element is present within the ExtData parameter.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter Description
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the credit card transaction. Valid values are:
Sale: Makes a credit card purchase.
Adjustment: Modifies the existing TipAmt, TaxAmt, TotalAmt, or
PONum for an original sale.
Support for this TransType is processor‐specific.
Auth: Authorizes an amount on a credit card.
Return: Credits the cardholder’s account.
Void: Removes an unsettled transaction from the open batch. Pass
null values for CardNum and ExpDate when running void
transactions.
Force: Places an Auth transaction into the current batch (PostAuth)
or places a transaction that is unprocessed by the payment server
into the current batch (ForceAuth).
Capture: Settles a single transaction in the current batch; only for
terminal‐based processors.
CaptureAll: Settles all transactions in the current batch; only for
terminal‐based processors or host‐based processors that support a
batch release feature.
22
Parameter Description RepeatSale: Performs a recurring billing or installment payment transaction.
Reversal: Performs a manual full reversal on a credit sale or repeat sale. Reversals must process within 24 hours of the original transaction.
CardNum Optional for all TransTypes but Sale, Auth, Return, and Force (ForceAuth). Credit card number.
ExpDate Optional for all TransTypes but Sale, Auth, Return, and Force (ForceAuth). Credit card’s expiration date in MMYY format.
MagData Required for swiped card transactions. Data located on the track 2 of the card’s magnetic strip. Once this field is populated, the transaction is a card‐present transaction and usually results in a more favorable retail discount rate.
The format of the MagData (or track 2 data) is CardNum=ExpDate + the service code + the checksum. For example, 36438999960016=05121015432112345678.
This parameter removes invalid characters. See XML Character Removal on page 172 for more details.
NameOnCard Optional, depending on different merchant processor setups. The cardholder’s name as it appears on the card. This parameter removes
invalid characters. See XML Character Removal on page 172 for more
details.
Amount Required for Auth, Sale, Return, Force (both PostAuth and ForceAuth) TransTypes. The total transaction amount in DDDD.CC format.
InvNum Optional. Invoice tracking number. This parameter removes invalid
characters. See XML Character Removal on page 172 for more details. See table A3 in Appendix for Invoice formatting by Processor.
PNRef Required for Void, Force (PostAuth), and Capture TransTypes. Reference number assigned by the payment server.
Zip Optional, depending on different merchant processor setups. The ZIP code from the cardholder billing address that is used in address
verification. This parameter removes invalid characters. See XML
Character Removal on page 172 for more details.
Street Optional, depending on different merchant processor setup. Street address from cardholder’s billing address that is used in address verification. This parameter removes invalid characters. See XML
Character Removal on page 172 for more details.
CVNum Optional. Card Verification Number. A 3 or 4‐digit security code that is printed on the front or back of a card but not encoded on the magnetic
stripe data.
23
Parameter Description ExtData Optional unless otherwise noted below or in Processor Addendum on page 78. Extended data in XML format. Valid values are:
<AuthCode>Code</AuthCode> Original authorization code. Required for ForceAuth transactions.
<CustCode>Code</CustCode> Customer code or PO number of the customer. The data within this XML tag parameter removes invalid characters See XML Character Removal on page 172 for more details.
<ConvenienceAmt>Amount</ConvenienceAmt> Convenience amount in DDDD.CC format.
<TipAmt>Amount</TipAmt> Tip amount in DDDD.CC format.
<TaxAmt>Amount</TaxAmt> Tax amount in DDDD.CC format.
<TotalAmt>Amount</TotalAmt> Total amount in DDDD.CC format.
<SequenceNum>Num</SequenceNum> Sequence number used with RepeatSale installments that designates which number in the sequence the transaction is. Must be a positive integer less than or
equal to SequenceCount.
<SequenceCount>SequenceCount</SequenceCount> Used with RepeatSale installment transactions. Designates the total number of charges to be charged. Must be a positive integer greater than
or equal to SequenceNum.
<ServerID>ID<ServerID> Unique server identification number. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
<TimeOut>TimeOut</TimeOut> for timeout value in seconds (default value is 40 for a transaction, 300 for a settlement transaction).
<TrainingMode>Mode</TrainingMode> Enables/disables Training Mode. Valid values are: T, F.
<TransactionID>ID</TransactionID> Numerical string value that you can pass with the original request to identify a transaction. May be used for identification and voids. Please see Credit Void
with Transaction ID page 32 for a detailed example.
<Target>Target</Target> Identifies the TransactionID of the original transaction you wish to void.
<Force>Force</Force> Enables/disables the processing of this current transaction if it is a duplicate transaction. Valid values are: T, F.
<RegisterNum>Num</RegisterNum> Register number. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
24
Parameter Description
<City>City</City> City of the cardholder's billing address. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
<BillToState>State</BillToState> Two‐character state code of
the cardholder's billing address. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
<CustomerID>ID</CustomerID> Customer ID.
<PONum>Num</PONum> Purchase Order Number. The data
within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions. This tag is only relevant in Retail, MOTO, and eCommerce markets.
<Authentication> Required to process a transaction using Visa’s
Verified By Visa and MasterCard’s SecureCode programs.
<XID>AuthenticationID</XID> The Unique Transaction Identifier (applies to Verified By Visa) <UCAF>UCAF</UCAF> Universal Card Holder Authentication (applies to MasterCard’s SecureCode).
Verified by Visa may return a CAVV value in the response ExtData.
<TrustAttempt>T</TrustAttempt> Indicates Verified By Visa or SecureCode attempted, but there was no XID or UCAF available for the transaction. Valid values are: T, F.
</Authentication>
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<Presentation> Indicates card presence in a transaction.
<CardPresent>CardPresent Value</CardPresent> Valid values are: True: Card is present. False: The card is not present or unknown.
</Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY. <TPP ID> tppid </TPP ID > Id for Conttactless needed by Omaha.
<Invoice> Required for Level III purchase card processing but
25
Parameter Description
optional for fuel purchases. Indicates the beginning of invoice details.
All elements within Invoice are processed sequentially, so they must be sent in the order listed below.
<InvNum>Num</InvNum> Purchase invoice number.
<Date>Date</Date> Date of invoice in YYMMDD format. <BillTo>
<CustomerId>ID</CustomerId> Customer ID number.
<Name>Name</Name> Customer
name. <Address> Customer address.
<Street>Street</Street> Street of customer’s
address. <City>City</City> City of customer’s address.
<State>State</State> State of customer’s address.
<Zip>ZIP</Zip> ZIP code of customer’s address.
<Country>Country</Country> Country of customer’s address.
<Description>Description</Description> Description of purchase.
<Items> Required for Level III purchase card and fuel purchases (Sale and Force TransTypes). Items contained in invoice. Contains one or more Item elements.
<Item>One item in invoice. There may be multiple Item tags within the Items tag.
<SKU>SKU</SKU> SKU number of item.
<UPC>UPC</UPC> Required for Level III purchase card processing and fuel purchases. Valid values depend on the type of purchase: For purchase card Level III processing: The UPC
26
Parameter Description
number of item. For fuel processing: National Association of Convenience Stores (NACS) product code.
<Quantity>Quantity</Quantity> Required for Level III purchase card processing and fuel purchases. Quantity of item purchased.
<UnitOfMeasurement>Unit</UnitOfMeasurement> Unit of measurement for item.
<UnitPrice>Price</UnitPrice> Required for Level III purchase card processing and fuel purchases. Unit price of item.
<DiscountAmt>Amount</DiscountAmt> Discount amount on item. <TaxAmt>Amount</TaxAmt> Tax amount on item. <TotalAmt>Amount</TotalAmt> Total amount of item.
<Category>Category</Category> Required for Level III purchase card processing and fuel purchases. Item category. If making a fuel purchase, the value is Fuel. <TaxRate>Rate</TaxRate> Tax rate applied to item.
</Item> </Items>
<DiscountAmt>Amount</DiscountAmt> Total discount for invoice.
<ShippingAmt>Amount</ShippingAmt> Shipping amount for invoice. <DutyAmt>Amount</DutyAmt> Duty amount for invoice <TaxAmt>Amount </TaxAmt> Tax amount for invoice.
<NationalTaxInc>NationalTax</NationalTaxInc> Additional tax amount included in invoice total.
<TotalAmt>Amount</TotalAmt> Total amount of the transaction on the invoice.
</Invoice>
<Fleet> Required for fleet card purchases (Sale and Force TransTypes). Information on fleet member making purchase.
Please note that all elements nested within Fleet are processed sequentially, so they must be in the order listed below.
<VehicleNum>Num</VehicleNum> May be required for specific
27
Parameter Description
purchases. Vehicle number.
<DriverNum>Num</DriverNum> May be required for specific purchases. The vehicle driver’s number.
<OdometerReading>Reading</OdometerReading> May be required for specific purchases. The current odometer reading of the fleet vehicle.
</Fleet>
<CardType>Type</CardType> Describes the payment methods to settle or card type. Requirements and values depend on TransType:
‐ Capture: This element does not apply to the Capture TransType
as only one transaction settles. ‐ CaptureAll: Optional. Valid values are:
ALL to specify all payment methods to settle.
A combination of the specific payment methods to settle, separated by a colon (e.g., CREDIT:DEBIT:EBT:EGC).
Host‐based processors that support a manual batch settlement require all payment methods to be settled at the same time.
‐ All other TransTypes: Required for manually entered fleet card transactions where the ISO prefix of the card is only present on the track data (not embossed on the front of the card). Valid values are: WEX, Voyager.
<DebugData> Simulates scensarios for QA. Available in Debug
versions only. <ForceFinishFailure>T</ForceFinishFailure> Valid values are: T, F. Behavior is dependent on TransType:
Standard Transaction (e.g., Sale): Exception thrown prior to final database write. QA/Debug.
Auto‐Reversal: status of void/reversal returned to user. QA. Capture: In a multi‐segment batch, the second segment fails. QA/Regression.
<SerializeProcessorHandler2Data>T</SerializeProcessorHandle r2Data> Serializes the objects associated with the Process and ProcessSettle interface methods via Log4Net. Informational. Valid values are: T, F.
<ForceAdjustmentTransactionFailure>T</ForceAdjustmentTran sactionFailure> Generates an Adjustment transaction exception before the final adjustment of the original record. Simulates cloned records but does not adjust the original transaction. QA/Debug. Valid values are: T, F.
28
Parameter
Description
</DebugData>
2.3.1. Purchase Card Level III Data
PathwayLINK supports purchase card Level III data for credit transactions. Located in the ExtData, Invoice and its child elements pass invoice information in line‐item detail to processors for verification.
Not all processors support this functionality. For more information on this feature and its supporting processors, please see Processor Addendum on page 78.
2.3.2. Fuel Purchases
PathwayLINK supports fuel purchases on both standard credit and fleet cards using the Items element nested under Invoice.
Not all processors support this functionality. For more information on this feature and its supporting processors, please see Processor Addendum on page 78.
2.3.3. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.3.3.1. Manual Credit Sale
The following example processes a manually‐entered credit Sale transaction. Because the ExtData field has Force set to T, the payment processes, even if it is a duplicate transaction.
The following example processes a credit Void transaction. The request identifies the transaction to void using the PNRef from the original transaction.
You must pass null values for the card number and ExpDate on void transactions.
</Response> 2.3.3.5. Credit Void with Transaction ID
The following example processes a credit Void transaction using the TransactionID element. Note that in order to void a transaction using its Transaction ID, you must send it within the ExtData of the original transaction.
For illustrative purposes, this example includes the original sale transaction.
The following example processes a credit Capture transaction to settle a single transaction in the current batch. The request targets the individual transaction using its PNRef.
</ExtData> </Response> Multi-Batch Success The example below shows the response detail of a successful multiple batch settlement. Note that the ExtData has three Detail child elements, one for each batch. <?xml version="1.0" encoding="utf-8" ?> <Response xmlns:xsd="http://www.w3.org/2001/XMLSchema"
In a multi‐batch settlement, you may receive a partially successful response if the individual batches have mixed results. Note that in the ExtData, only the third Detail element has a successful Result Code (Result = 0).
CardType=ALL,Net_Count=1,Net_Amount=-1.00,Settle_DT=2006-06-27 12:48:15,BatchNum=262,Batch= <Summary>Net_Count=1,Net_Amount=-1.00,Settle_DT=2006-06-27 12:48:15,Result=15</Summary> <Detail>Net_Count=4,Net_Amount=-4.00,Settle_DT=2006-06-27 12:48:15,Result=12,Number=262,Message=RB E 0004 D 24</Detail> <Detail>Net_Count=4,Net_Amount=-4.00,Settle_DT=2006-06-27 12:48:17,Result=12,Number=262,Message=RB E 0006 D 24</Detail> <Detail>Net_Count=1,Net_Amount=-1.00,Settle_DT=2006-06-27 12:48:19,Result=0,Number=262,AuthCode=GB00262 ACCEPTED,Message=ACCEPTED</Detail>
</ExtData> </Response>
2.3.3.11. Credit RepeatSale
The following example processes a credit RepeatSale transaction as a recurring payment based on the PNRef number of a previous sale transaction.
To add a tip to the original sale transaction, you must send an adjustment transaction with credentials, the PNRef of the original sale, and a TipAmt in the ExtData.
The following example processes a credit Reversal transaction.
Reversal transactions are not supported by all processors, and there may be processor‐specific requirements that differ than the data shown below. See Processor Addendum on page 78 for more information.
40
For illustrative purposes, this example includes the original sale transaction.
Original Sale Transaction
Parameter Value
UserName Test
Password 123
TransType Sale
CardNum 5439750001500347
ExpDate 1211
NameOnCard John Smith
Amount 10.00
InvNum 12345
CVNum 998
Response
<?xml version="1.0" encoding="utf-8" ?>
<Response xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="https://gateway.itstgate.com/SmartPayments/"> <Result>0</Result> <RespMSG>Approved</RespMSG> <Message>APPROVAL TAS275</Message> <AuthCode>TAS275</AuthCode> <PNRef>23851</PNRef> <HostCode>833115500058</HostCode> <GetAVSResult>0</GetAVSResult> <GetAVSResultTXT>Issuer did not perform AVS</GetAVSResultTXT> <GetStreetMatchTXT>Service Not Requested</GetStreetMatchTXT> <GetZipMatchTXT>Service Not Requested</GetZipMatchTXT> <GetCVResult>M</GetCVResult> <GetCVResultTXT>Match</GetCVResultTXT> <GetCommercialCard>False</GetCommercialCard> <ExtData>InvNum=12345,CardType=MASTERCARD</ExtData>
</Response>
Reversal Transaction To target a sale transaction, the reversal transaction uses the PNRef returned in the original sale transaction’s response.
The following example processes a credit Sale transaction with the CVPresence element. Note that the request uses the extended 9‐digit ZIP code and the CV presence of the card is marked Illegible in the ExtData.
xmlns="https://gateway.itstgate.com/SmartPayments/"> <Result>0</Result> <RespMSG>Approved</RespMSG> <Message>APPROVAL TAS275</Message> <AuthCode>TAS275</AuthCode> <PNRef>23851</PNRef> <HostCode>833115500058</HostCode> <GetAVSResult>0</GetAVSResult> <GetAVSResultTXT>Issuer did not perform AVS</GetAVSResultTXT> <GetStreetMatchTXT>Service Not Requested</GetStreetMatchTXT> <GetZipMatchTXT>Service Not Requested</GetZipMatchTXT> <GetCVResult>M</GetCVResult> <GetCVResultTXT>Match</GetCVResultTXT> <GetCommercialCard>False</GetCommercialCard> <ExtData>InvNum=12345,CardType=MASTERCARD</ExtData>
</Response>
2.3.3.15. Credit Sale with Contactless
The following example processes a credit Sale transaction with the Proximity element. Note that the request uses the Entry mode element to denote a NFC or contactless transaction. The MagData field is where you pass your NFC payload.
xmlns="https://gateway.itstgate.com/SmartPayments/"> <Result>0</Result> <RespMSG>Approved</RespMSG> <Message>APPROVAL TAS275</Message> <AuthCode>TAS275</AuthCode> <PNRef>23851</PNRef> <HostCode>833115500058</HostCode> <GetAVSResult>0</GetAVSResult> <GetAVSResultTXT>Issuer did not perform AVS</GetAVSResultTXT> <GetStreetMatchTXT>Service Not Requested</GetStreetMatchTXT> <GetZipMatchTXT>Service Not Requested</GetZipMatchTXT> <GetCVResult> Service Not Requested </GetCVResult> <GetCVResultTXT>Match</GetCVResultTXT> <GetCommercialCard>False</GetCommercialCard> <ExtData>InvNum=12345,CardType=VISA</ExtData>
</Response>
2.4. ProcessDebitCard
This Web service operation processes debit card transactions for a merchant. The URL to access this operation is:
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter Description
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the debit card transaction. Valid values are:
Sale: Makes a debit card purchase.
Return: Credits the cardholder’s account.
Capture: Settles a single transaction in the current batch; only for
terminal‐based processors.
CaptureAll: Settles all transactions in the current batch; only for
terminal‐based processors or host‐based processors that support
a batch release feature.
Reversal: Performs a manual full reversal on a debit sale or repeat
sale. Reversals must process within 24 hours of the original
transaction.
43
Parameter
Description
CardNum Required for all TransTypes except Capture and CaptureAll. Debit
card number.
ExpDate Required for all TransTypes except Capture and CaptureAll. Debit
card’s expiration date in MMYY format.
MagData Required for all TransTypes except Capture and CaptureAll. Data
located on the track 2 of the magnetic strip of the card. Once this field
is populated, the transaction is a card‐present transaction and usually
results in a more favorable retail discount rate.
The format of the MagData (or Track 2 data) is CardNum=ExpDate +
the service code + the checksum. For example,
36438999960016=05121015432112345678.
This parameter removes invalid characters. See XML Character
Removal on page 172 for more details.
NameOnCard Optional, depending on different merchant processor setups. The
cardholder’s name as it appears on the card. This parameter removes
invalid characters. See XML Character Removal on page 172 for more
details.
Amount Required for all TransTypes except CaptureAll. The total transaction
amount in DDDD.CC format. This amount includes CashBackAmt and
SureChargeAmt.
InvNum Optional. Invoice tracking number. This parameter removes invalid
characters. See XML Character Removal on page 172 for more
details. See table A3 in Appendix for Invoice formatting by Processor.
PNRef Optional except for Force and Capture TransTypes. Reference number
assigned by the payment server.
Pin Required except for Capture, CaptureAll, and PIN‐less debit
transactions. The encrypted PIN block returned by the PIN pad. The
transaction fails if an unencrypted PIN value is used.
RegisterNum Optional. A number that uniquely identifies the register or computer
performing transactions. This parameter removes invalid characters.
See XML Character Removal on page 172 for more details.
SureChargeAmt Optional. The fee a merchant charges for processing debit
transactions. In DDDD.CC format.
CashBackAmt Optional. The amount a cardholder requests for cash back. In
DDDD.CC format.
ExtData Optional unless otherwise noted below or in Processor Addendum on
page 78. Extended data in XML format. Valid values are:
Extended data in XML format. Valid values are:
<TimeOut>TimeOut</TimeOut> Timeout value in seconds.
44
Parameter Description
Default value is 40.
<TrainingMode>Mode </ TrainingMode> Enables/disables processing transaction in Training Mode. Valid values are: T, F.
<KeySerialNumber>Number</ KeySerialNumber> Required for all Sale, Auth, Force, and Return transactions that require PIN. Manages DUKPT PIN pads transactions that require PIN input.
<Force>Force</Force> Enables/disables the processing of this current transaction if it is a duplicate transaction. Valid values are: T, F.
<Items> Required for purchase card Level III processing and fuel purchases. Items contained in invoice. Contains one or more Item elements.
<Item>One item in invoice.
<SKU>SKU</SKU> SKU number of item.
<UPC>UPC</UPC> Required for purchase card –Level III and fuel purchases. UPC number of item for purchase card ‐ Level III processing or the NACS (National Association of Convenience Stores) product code for fuel purchases. <Description>Description</Description> Item description.
<Quantity>Quantity</Quantity> Required for purchase card ‐Level III processing and fuel purchases. Quantity of item purchased.
<UnitOfMeasurement>Unit</UnitOfMeasurement> Unit of measurement for item.
<UnitPrice>UnitPrice</UnitPrice> Required for purchase card Level III processing and fuel purchases. Unit price of item.
<DiscountAmt>DiscountAmount</DiscountAmt> Discount amount on item.
<TaxAmt>Amount</TaxAmt> Tax amount on item.
<TotalAmt>Amount</TotalAmt> Total amount of item.
<Category>Category</Category> Required for for purchase card Level III processing and fuel purchases. Item category for Purchase Card Level III or Fuel to designate a fuel purchase item. <TaxRate>TaxRate</TaxRate> Tax rate applied to item.
</Item> </Items>
<DebugData> Simulates scensarios for QA. Available in Debug versions only.
Standard Transaction (e.g., Sale): Exception thrown prior to final database write. QA/Debug.
Auto‐Reversal: status of void/reversal returned to user. QA.
Capture: In a multi‐segment batch, the second segment fails. QA/Regression.
<SerializeProcessorHandler2Data>T</SerializeProcessorHandl er2Data> Serializes the objects associated with the Process and ProcessSettle interface methods via Log4Net. Informational. Valid values are: T, F.
<ForceAdjustmentTransactionFailure>T</ForceAdjustmentTra nsactionFailure> Generates an Adjustment transaction exception before the final adjustment of the original record. Simulates cloned records but does not adjust the original transaction. QA/Debug. Valid values are: T, F.
</DebugData>
2.4.1. PIN-less Debit Transactions
PathwayLINK supports the ability to process a debit transaction without the customer’s PIN, a “PIN‐less” debit transaction. The transaction sends the same information as a typical PIN‐based debit transaction, with the exception of the encrypted PIN‐block and Key Serial Number. This functionality is only supported by certain processors. See Processor Addendum on page 78 for more information.
2.4.2. Debit Fuel Purchases
PathwayLINK supports fuel purchases using standard debit cards. Debit fuel purchases require passing item‐level purchase information to the gateway to ensure correct processing. This functionality is only supported by certain processors. See Processor Addendum on page 78 for more information.
2.4.3. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
46
2.4.3.1. Swiped Debit Sale
The following example processes a swiped debit Sale transaction. Note that the sale amount of $6.00 includes a cash back amount of $5.00.
The following example processes a manual debit Reversal transaction.
Reversal transactions are not supported by all processors, and processor‐specific requirements may differ than those shown below. See Processor Addendum on page 78 for more information.
For illustrative purposes, this example includes the original sale transaction.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter Value UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the EBT card transaction. Valid values are:
FoodStampSale: Makes a purchase on an EBT cardholder’s food stamp account.
FoodStampReturn: Applies a credit to an EBT cardholder’s food stamp account.
CashBenefitSale: Makes a purchase on an EBT cardholder’s cash benefit account.
Inquire: Checks the balance of an EBT cardholder’s account.
Capture: Settles a single transaction in the current batch; only for terminal‐based processors.
CaptureAll: Settles all transactions in the current batch; only for terminal‐based processors or host‐based processors that support a
batch release feature.
Force (Voucher Clear): Allows a merchant perform a PIN‐less EBT sale by passing a voucher number and an authorization code obtained via voice approval.
CardNum Required for all TransTypes but Capture and CaptureAll. EBT card number to process the transaction.
ExpDate Required for all TransTypes but Capture and CaptureAll. EBT card’s expiration date in MMYY format.
50
Parameter Value MagData Required for swiped card transactions. Data located on the track 2 of the card’s magnetic strip. Once this field is populated, the transaction is a card‐present transaction and usually results in a more favorable retail discount rate.
The format of the MagData (or Track 2 data) is CardNum=ExpDate + the service code + the checksum. For example, 36438999960016=05121015432112345678.
This parameter removes invalid characters. See XML Character Removal on page 172 for more details.
NameOnCard Optional, depending on different merchant processor setup. The cardholder’s name as it appears on the card.
Amount Required for all TransTypes but CaptureAll. The total transaction amount in DDDD.CC format. This amount includes CashBackAmt and SureChargeAmt.
InvNum Optional. Invoice tracking number. This parameter removes invalid
characters. See XML Character Removal on page 172 for more details. See table A3 in Appendix for Invoice formatting by Processor.
PNRef Optional for all TransTypes but Capture and FoodStampReturn. The reference number assigned by the payment server.
Pin Required for all TransTypes except for Capture and CaptureAll. The encrypted PIN block returned by the PIN pad. The transaction fails if an
unencrypted PIN value is used.
RegisterNum Optional. A number uniquely identifies a register or computer, on which the transaction is performed. This parameter removes invalid
characters. See XML Character Removal on page 172 for more details.
SureChargeAmt Optional. The fee a merchant charges for processing an EBT card transaction. In DDDD.CC format.
CashBackAmt Optional, and only applies to CashBenefitSale TransType. The amount a cardholder requests for cash back. In DDDD.CC format.
ExtData Optional unless otherwise noted below or in Processor Addendum on page 78. Extended data in XML format. Valid values are:
<TimeOut>TimeOut</TimeOut> for timeout value in seconds (default = 40).
<TrainingMode>Mode</TrainingMode> to process transaction in Training Mode. Valid values are: T, F.
<KeySerialNumber>Number</KeySerialNumber > Required for all FoodStampSale, FoodStampReturn, CashBenefitSale, and Inquire transactions that require PIN. Manages DUKPT PIN pads transactions that require PIN input.
<Force>Force</Force> Enables/disables the processing of this
51
Parameter
Value
current transaction if it is a duplicate transaction. Valid values are:
T, F.
<AuthCode>Code</AuthCode> Original authorization code.
Standard Transaction (e.g., Sale): Exception thrown prior to
final database write. QA/Debug.
Auto‐Reversal: status of void/reversal returned to user. QA.
Capture: In a multi‐segment batch, the second segment fails.
QA/Regression.
<SerializeProcessorHandler2Data>T</SerializeProcessorHandle r2Data> Serializes the objects associated with the Process and ProcessSettle interface methods via Log4Net. Informational. Valid values are: T, F.
<ForceAdjustmentTransactionFailure>T</ForceAdjustmentTran sactionFailure> Generates an Adjustment transaction exception before the final adjustment of the original record. Simulates cloned records but does not adjust the original transaction. QA/Debug. Valid values are: T, F.
</DebugData>
2.5.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.5.1.1. Swiped EBT Food Stamp Sale
The following example processes a swiped EBT FoodStampSale transaction.
The following example processes an EBT Force (Voucher Clear) transaction that allows for a merchant to perform a PIN‐less EBT transaction using the voucher slip reference number and an authorization code obtained through a voice approval.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
55
Parameter Value UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the gift card transaction. Valid values are:
Redeem: Makes a purchase on a gift card.
Reload: Increases the balance on a gift card.
Refund: Refunds money back to a gift card.
Activate: Activates a gift card.
Deactivate: Deactivates a gift card.
Inquire: Checks the balance on a gift card.
Void: Undoes an unsettled transaction.
Capture: Settles a single transaction in the current batch; only for terminal‐based processors.
CaptureAll: Settles all transactions in the current batch or host‐ based processors that support a batch release feature.
CardNum Required. Gift card number used to process the transaction.
ExpDate Required. Gift card’s expiration date in MMYY format.
MagData Required for swiped card transactions. Data located on the track 2 of the card’s magnetic strip. Once this field is populated, the transaction is a card‐present transaction and usually results in a more favorable retail
discount rate.
The format of the MagData (or Track 2 data) is CardNum=ExpDate + the service code + the checksum. For example, 36438999960016=05121015432112345678.
This parameter removes invalid characters. See XML Character Removal on page 172 for more details.
Amount Required for all TransTypes except Inquire. The total transaction amount in DDDD.CC format.
InvNum Optional. Invoice tracking number. This parameter removes invalid
characters. See XML Character Removal on page 172 for more details. See table A3 in Appendix for Invoice formatting by Processor.
PNRef Optional for all TransTypes except Void. Reference number assigned by the payment server.
ExtData Optional unless otherwise noted below or in Processor Addendum on page 78. Extended data in XML format. Valid values are:
<TrainingMode>Mode</TrainingMode> Enables/disables Training Mode. Valid values are: T, F.
<Force>Force</Force> Enables/disables the processing of this current transaction if it is a duplicate transaction. Valid values are:
56
Parameter Value T, F.
<TimeOut>TimeOut</TimeOut> Timeout value in seconds (default value is 40).
<RegisterNum>Num</RegisterNum> Register number. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
<AuthCode>Code</AuthCode> Required for Force transactions. Original authorization code of a previously authorized Redeem transaction. See Gift Force Transactions on page 57 for more information.
<ForceAuth> Required for previously authorized Redeem, Reload, or Activate transactions if the request is placing them into the current batch. See Gift Force Transactions on page 57 for more information. <AuthCode>Code</AuthCode> Original authorization code of previous Redeem, Reload, or Activate transaction.
</ForceAuth>
<DebugData> Simulates scensarios for QA. Available in Debug versions only.
<ForceFinishFailure>T</ForceFinishFailure> Valid values are: T, F. Behavior is dependent on TransType:
Standard Transaction (e.g., Sale): Exception thrown prior to final database write. QA/Debug.
Auto‐Reversal: status of void/reversal returned to user. QA. Capture: In a multi‐segment batch, the second segment fails.
QA/Regression.
<SerializeProcessorHandler2Data>T</SerializeProcessorHandle r2Data> Serializes the objects associated with the Process and ProcessSettle interface methods via Log4Net. Informational. Valid values are: T, F.
<ForceAdjustmentTransactionFailure>T</ForceAdjustmentTran sactionFailure> Generates an Adjustment transaction exception before the final adjustment of the original record. Simulates cloned records but does not adjust the original transaction. QA/Debug. Valid values are: T, F.
</DebugData>
2.6.1. Gift Force Transactions
PathwayLINK supports Force (ForceAuth) transactions for previously authorized Redeem, Reload, and Activate transactions.
57
Not all processors support this functionality. For more information on this feature and its supporting processors, please see Processor Addendum on page 78.
2.6.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.6.2.1. Swiped Gift Redeem
The following example processes a swiped Redeem transaction on a gift card. The ExtData includes the enabled Force element to ensure processing even if this is a duplicate transaction.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
Parameter
Value
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
TransType Required. Type of the loyalty card transaction. Valid values are:
Redeem: Makes a purchase on a loyalty card.
Reload: Increases the balance on a loyalty card.
Refund: Refunds value back to a loyalty card.
Activate: Activates a loyalty card.
Deactivate: Deactivates a loyalty card.
Inquire: Checks the balance on a loyalty card.
Void: Removes an unsettled transaction from the open batch.
Capture: Settles a single transaction in the current batch; only for
terminal‐based processors.
CaptureAll: Settles all transactions in the current batch or host‐
based processors that support a batch release feature.
CardNum Required. Loyalty card number used to process the transaction.
ExpDate Required. Loyalty card’s expiration date in MMYY format.
MagData Required for swiped card transactions. Data located on the track 2 of
the card’s magnetic strip. Once this field is populated, the transaction is
a card‐present transaction and usually results in a more favorable retail
discount rate.
The format of the MagData (or Track 2 data) is CardNum=ExpDate +
the service code + the checksum. For example,
36438999960016=05121015432112345678.
This parameter removes invalid characters. See XML Character
Removal on page 172 for more details.
Amount Required for all TransTypes except Inquire. The total transaction
amount in DDDD.CC format.
InvNum Optional. Invoice tracking number. This parameter removes invalid
characters. See XML Character Removal on page 172 for more details. See table A3 in Appendix for Invoice formatting by Processor.
PNRef Optional for all TransTypes except Void. Reference number assigned by
the payment server.
59
Parameter Value ExtData Optional unless otherwise noted below or in Processor Addendum on
page 78. Extended data in XML format. Valid values are:
<TrainingMode>Mode</TrainingMode> Enables/disables Training Mode. Valid values are: T, F.
<Force>Force</Force> Enables/disables the processing of this current transaction if it is a duplicate transaction. Valid values are: T, F.
<TimeOut>TimeOut</TimeOut> Timeout value in seconds (default value is 40).
<RegisterNum>Num</RegisterNum> Register number. The data within this XML tag parameter removes invalid characters. See XML Character Removal on page 172 for more details.
2.7.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.7.1.1. Loyalty Redeem
The following example processes a Redeem transaction for a loyalty card.
The following table contains parameter descriptions.
Not all processors support all of the following features, and some processors may have additional functionality or custom requirements not listed below. Please reference the Processor Addendum on page 78 for additional information and to verify the supported functionality for your processor(s).
61
Parameter Value
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
SignatureType Required. Type of signature to capture. Valid values are:
Signature1: Legacy format for Lipman credit.
Signature2: Legacy format for Lipman check.
Signature3: Legacy format for handheld applications using
AppForge.
Signature4: Standard vector coordinate format.
Receipt1: TIFF file.
SignatureData Required.
For Signature4: A string value of vector coordinates delimited with
a ^ character in the following format: x1,y1^x2,y2^xN,yN^~.
‐ The carat (^) is the coordinate delimiter.
‐ The tilde (~) is the ending delimiter.
‐ The comma (,) is the vector delimiter.
For pen‐up events, use the coordinate 0,65535 to signal
a break in the line.
For Receipt1: Compress and Base64 encode the image data. See
the following section, Creating a Receipt Image Transaction from a
File, for more information.
PNRef Required. The unique payment reference number assigned to the
transaction.
Result Optional. An indicator that specifies if the processed transaction was
approved.
AuthCode Optional. Original authorization code.
ExtData Optional unless otherwise noted below or in Processor Addendum on
page 78. Extended data in XML format. Valid values are:
<TrainingMode>Mode</TrainingMode> Enables/disables Training
Mode. Valid values are: T, F.
2.8.1. Creating a Receipt Image Transaction from a File
Due to the overall complexity of creating a receipt image with ProcessSignature, here is a general list of steps your client‐side application must perform in order to send images to the payment server:
1. If image is not already in TIF format, convert it now.
62
Perform LZW compression on the image data to reduce as the payment server rejects images larger than 25KB.
2. Compress the image using Zip compression to reduce the file size.
You may use any PKZip‐compatible Zip compressor/decompressor.
3. To ensure that the binary‐based information properly converts into text‐based
characters for ProcessSignature, use Base64 to encode the image.
4. Input the compressed, Base64‐encoded image data into the SignatureData parameter and send the request to the payment server.
2.8.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
2.8.2.1. Drawing a Square
The following example uses the Signature4 SignatureType to draw a square on the receipt and associates it with the transaction with a PNRef of 9568.
Parameter Value UserName test
Password 123
PNRef 9568
SignatureType Signature4
SignatureData 20,20^20,30^30,30^30,20^20,20^~
63
Result
2.8.2.2. Saving a Receipt Image
The following example uses the Receipt1 SignatureType to save a receipt image to the payment server and associate it with the transaction with a PNRef of 3.
Parameter Value hQLFAAAAAgAjYw/MofOK4WOCAAACj4AAD8AAAAAAAAAAAAgALaBAA AAAFByb2dyYW0gRmlsZXMvQ29tbW9uIEZpbGVzL1NtYXJ0UGF5bWVud HMgU2hhcmVkL1RlbXBSZWNlaXB0LmJtcFBLBQYAAAAAAQABAG0AAAD rCAAAAAA=
Result
2.8.2.3. Saving a Check Image
The following example uses the Receipt1 SignatureType to save a check image to the payment server and associate it with the transaction with a PNRef of 5454.
The following table contains descriptions of the result codes returned in the Result response field from PathwayLINK. Please note that when programmatically validating a transaction’s result, you should use this value instead of any other response message describing the result.
Value
Description
‐100 Transaction not processed; generic host error.
0 Approved.
1 User authentication failed.
73
Value
Description
2 Invalid transaction.
3 Invalid transaction type.
4 Invalid amount.
5 Invalid merchant information.
7 Field format error.
8 Not a transaction server.
9 Invalid parameter stream.
10 Too many line items.
11 Client timed out waiting for response.
12 Decline.
13 Referral.
14 Transaction type not supported in this version.
19 Original transaction ID not found.
20 Customer reference number not found.
22 Invalid ABA number.
23 Invalid account number.
24 Invalid expiration date.
25 Transaction type not supported by host.
26 Invalid reference number.
27 Invalid receipt information.
28 Invalid check holder name.
29 Invalid check number.
30 Check DL verification requires DL state.
40 Transaction did not connect (to NCN because SecureNCIS is not running on the
Web server).
50 Insufficient funds available.
99 General error.
100 Invalid transaction returned from host.
101 Timeout value too small or invalid timeout value.
102 Processor not available.
103 Error reading response from host.
74
Value
Description
104 Timeout waiting for processor response.
105 Credit error.
106 Host not available.
107 Duplicate suppression timeout.
108 Void error.
109 Timeout waiting for host response.
110 Duplicate transaction.
111 Capture error.
112 Failed AVS check.
113 Cannot exceed sales cap.
1000 Generic host error.
1001 Invalid login.
1002 Insufficient privilege or invalid amount.
1003 Invalid login blocked.
1004 Invalid login deactivated.
1005 Transaction type not allowed.
1006 Unsupported processor.
1007 Invalid request message.
1008 Invalid version.
1010 Payment type not supported.
1011 Error starting transaction.
1012 Error finishing transaction.
1013 Error checking duplicate.
1014 No records to settle (in the current batch).
1015 No records to process (in the current batch).
75
3.2.2. AVS Response Code
The following table contains the descriptions of possible response values returned for address verification (AVS).
If the response returned is blank for this specific field tag, there is a chance that your processor does not support these AVS codes.
Value
Description
‐100 Transaction not processed; generic host error.
X Exact; Address and nine‐digit ZIP match.
Y Yes: Address and five‐digit ZIP match.
A Address: Address matches, ZIP does not.
Z 5‐digit Zip: 5‐digit ZIP matches, address doesn’t.
W Whole Zip: 9‐digit ZIP matches, address doesn’t.
N No: Neither address nor ZIP matches.
U Unavailable: Address information not available.
G Unavailable: Address information not available for international transaction.
R Retry: System unavailable or timeout.
E Error: Transaction unintelligible for AVS or an edit error found in the message
prevents performing AVS.
S Not supported: Issuer doesn’t support AVS service.
B * Street match: Street addresses match for international transaction, but postal
code doesn’t.
C * Street address: Street addresses and postal code not verified for international
transaction.
D * Match: Street addresses and postal codes match for international transaction.
I * Not Verified: Address Information not verified for international transaction.
M * Match: Street addresses and postal codes match for international transaction.
P * Postal match: Postal codes match for international transaction, but street
address doesn’t.
0 ** No response sent.
5 Invalid AVS response.
* These values are Visa‐specific. ** These values are returned by the payment server and not the processor.
76
3.2.3. CV Response Code
The following table contains descriptions of the possible response values returned for a CVV2/CVC2/CID check.
If the response returned is blank for this specific field tag, there is a chance that your processor does not support these CVV response codes.
Value
Description
M CVV2/CVC2/CID Match.
N CVV2/CVC2/CID No Match.
P Not processed.
S Issuer indicates that the CV data should be present on the card, but the merchant
indicates that the CV data is not present on the card.
U Unknown: Issuer has not certified for CV or issuer has not provided
Visa/MasterCard with the CV encryption keys.
X Server provider did not respond.
77
Chapter 4. Processor Addendum
This section covers processor‐specific requirements, parameters, and elements. If you have questions regarding the information here or need additional help with your processor(s), please contact our integration specialists at [email protected].
4.1. American Express
This section details requirements and features specific to American Express. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise noted, assume that all parameters and elements inherit the same requirements as specified in main document.
4.1.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with American Express.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None,
<Phase>Phase</Phase> Required for Capture TransType. Indicates the settlement phase. Because American Express uses a two‐phase
settlement, you must perform two distinct calls, a submission and a confirmation of the result. Valid values are: Submit, Confirm.
4.1.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with American Express.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
78
Parameter
Description
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, [on card].
<Phase>Phase</Phase> Required for Capture TransType. Indicates
the settlement phase. Because American Express uses a two‐phase settlement, you must perform two distinct calls, a submission and a confirmation of the result. Valid values are: Submit, Confirm.
4.1.3. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with American Express.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None,
NotSubmitted, Submitted, Illegible, [on card].
<Phase>Phase</Phase> Required for Capture TransType. Indicates
the settlement phase. Because American Express uses a two‐phase
settlement, you must perform two distinct calls, a submission and a
confirmation of the result. Valid values are: Submit, Confirm.
4.1.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with American Express.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None,
<Phase>Phase</Phase> Required for Capture TransType. Indicates
the settlement phase. Because American Express uses a two‐phase
settlement, you must perform two distinct calls, a submission and a
confirmation of the result. Valid values are: Submit, Confirm.
79
4.1.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with American Express.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<Phase>Phase</Phase> Required for Capture TransType. Indicates the settlement phase. Because American Express uses a two‐phase settlement, you must perform two distinct calls, a submission and a confirmation of the result. Valid values are: Submit, Confirm.
4.1.6. Response Values
The following table contains descriptions of response values specific to American Express.
Additional information with details of the settled batch if you
perform a batch close.
‐ Net_Count: Total number of transactions in the closed batch. ‐ Net_Amount: Net amount of transactions in the closed batch.
‐ Settle_DT: The date and time of the requested batch close.
Batch=<Summary>Net_Count=3,Net_Amount=‐ 3.00,Settle_DT=2006‐06‐27 12:41:52,Result=0</Summary>This batch response information is not an XML string. <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, [on card].
<Phase>Phase</Phase> Required for Capture TransType. Indicates the settlement phase. Because American Express uses a two‐phase settlement, you must perform two distinct calls, a submission and a confirmation of the result. Valid values are: Submit, Confirm.
80
4.2. Ceridian Stored Value Solutions (SVS)
This section details requirements and features specific to Ceridian Stored Value Solutions (SVS). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise noted, assume that all parameters and elements inherit the same requirements as specified in main document.
4.2.1. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Ceridian Stored Value Solutions.
Parameter Description
TransType Adjustment: Modifies an existing TipAmt or TotalAmt for an original sale.
Deactivate: Not supported.
ExtData <ActivationType>ActivationType</ActivationType> Indicates the type of gift card activation. Valid values are: Issue, Virtual, Activate.
<PIN>PIN</PIN> Gift card PIN.
<TransSubType>TransSubType</TransSubType> Extension/qualifier for cashing out the value of a gift card. Valid values are: CashOut.
4.2.1.1. Transaction Subtypes: CashOut & Issue
To cash out the value of a gift card, run a Redeem transaction with an Amount of 0 and pass the TransSubType with a value of CashOut in the ExtData.
To perform a gift card issue, run an Activate transaction and pass ActivationType with a value of Issue in the ExtData.
4.2.2. Response Values
The following table contains descriptions of response values specific to Ceridian Stored Value Solutions (SVS).
Parameter Description
ExtData <ReceiptData> Indicates data that should print on the receipt. <Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
This section details requirements and features specific to Campus Card (CBORD). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise noted, assume that all parameters and elements inherit the same requirements as specified in main document.
4.3.1. Response Values
The following table contains descriptions of response values specific to Campus Card (CBORD).
Parameter
Description
ExtData <Patron>Patron</Patron>
4.4. Card Group
This section details requirements and features specific to Card Group. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise noted, assume that all parameters and elements inherit the same requirements as specified in main document.
4.4.1. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Card Group.
Parameter
Description
TransType Deactivate: PathwayLINK does not currently support reactivating
deactivated cards, so take care when exercising this TransType.
82
4.4.2. Response Values
The following table contains descriptions of response values specific to Card Group.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
</ReceiptData>
4.5. Certegy
This section details requirements and features specific to Certegy. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.5.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Certegy.
This section details requirements and features specific to Concord (EFSNet). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.6.1. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Concord (EFSNet).
Parameter Description
ExtData <Invoice> … <Items> <Item> … <UPC>UPC</UPC> NACS is an industry standard that Concord (EFSNet) uses. For a list of NACS product codes, please contact EFSNet customer support at [email protected] or 1‐877‐852‐2637.
…
84
Parameter Description
</Item> </Items> …
</Invoice>
<CardType>CardType</CardType> Concord (EFSNet) does not currently support manually entered Voyager cards.
4.6.1.1. Purchase Card Level III Data
Concord (EFSNet) supports purchase card Level III data for credit transactions using the Invoice element and its nested elements. See Swiped Credit Sale with Purchase Card Level‐III Data on page 86 for a detailed example.
Some of Invoice’s child elements share the same purpose as other parameters and
ExtData elements. In the event that you specify a value in multiple places, the elements within Invoice take precedence. For example, if you populate values for the TaxAmt element within Invoice and the freestanding ExtData TaxAmt element, the system ignores the latter.
4.6.1.2. Fuel Purchases
Concord (EFSNet) supports fuel purchases on both standard and fleet cards using the Items element in the ExtData. Though the Invoice tag is not required for fuel transactions, the Items tag and its child elements are. You can pass Items alone or as a child element of Invoice.
Standard Credit Cards The Items tag holds one or more Item elements that contain details of each item from an invoice. Within each Item element are several description tags, including Category. In order to mark a transaction for fuel processing, at least one Item in a request must have a Category value of Fuel. See Swiped Credit Sale with Purchase Card Level‐III Data on page 86 and Swiped Credit Sale Fuel Transaction on page 87 for detailed examples.
Fleet Cards Concord currently supports fuel purchases on WEX, Voyager, and MasterCard Fleet cards. Like standard credit cards, fleet cards require at least on Item with a Category of Fuel.
In some cases, fleet cards can purchase non‐fuel items on a transaction marked for fuel processing, but Item‐level information must be present for all items in the transaction. Contact our integration specialists at [email protected] for more information.
Fleet requests require an additional tag, Fleet, for Sale, Auth, Force, and Return transactions. The child elements of Fleet (VehicleNum, DriverNum, OdometerReading) provide additional member information and may or may not be required, depending on the type of fleet card. For
85
example, WEX card transactions typically require DriverNum. See Swiped Fleet Sale on page for 88 a detailed example.
Fleet cards are unique in that the account data embossed on a card is often not the same as the track data. This poses a problem for manually entered fleet transactions where the card type is usually discerned from the account number. For this reason, manual fleet transactions require the CardType tag when the embossed data does not include the fleet ISO prefix. At present, Concord (EFSNet) doesn’t support manually entered Voyager cards, so the only valid value is WEX. See Manually Entered Fleet Sale on page 89 for a detailed example.
Typically, attempting to run a fleet transaction without Fleet data generates an error. MasterCard Fleet is the exception, allowing manual transactions to process without fleet data. If you run a MasterCard Fleet card without passing Fleet data, the transaction processes as if it were a standard credit fuel transaction.
Because MasterCard Fleet does not require Fleet data, the CardType element does not apply.
4.6.1.3. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.6.1.3.1. Swiped Credit Sale with Purchase Card Level-III Data
The following example processes a swiped credit Sale transaction as a fuel transaction. Because this is a fuel purchase, the ExtData includes one Item with a Category value of Fuel. This transaction also makes use of the optional Invoice tag to send purchase card level‐3 data.
Parameter Value
UserName Test
Password 123
TransType Sale
CardNum 5233272716340016
ExpDate 0208
MagData 5233272716340016=080212121228
NameOnCard John Doe
Amount 26.50
ExtData <Invoice><InvNum>123</InvNum><Date>050421</Date><BillTo><Cust omerId>CID101</CustomerId><Name>John Doe</Name><Address><St reet>123 Main Street</Street><City>Any City</City><State>WA</State
</Response> 4.6.1.3.2. Swiped Credit Sale Fuel Transaction
The following example processes a swiped credit Sale transaction as a fuel transaction. Because this is a fuel purchase, the ExtData includes one Item with a Category value of Fuel.
The following example processes a swiped Fleet Sale transaction as a fuel transaction. Note that the ExtData contains both required and optional tags for this transaction.
</Response> 4.6.1.3.4. Manually Entered Fleet Sale
The following example processes a manually entered fleet Sale transaction as a fuel transaction. Because this is a manual fleet sale, the ExtData contains the CardType in addition to the fleet and level‐3 data.
The following table contains additional information for using the ProcessDebitCard Web service operation with Concord EFSNet.
Parameter
Description
TransType Auth: Authorizes an amount on a debit card.
Force: Places and Auth transaction into the current batch
(PostAuth).
4.6.2.1. PIN-less Debit Transactions
Concord (EFSNet) supports PIN‐less processing for qualifying debit transactions.
To perform a PIN‐less debit transaction, your request requires all of the same information in a typical PIN‐based transaction except for the encrypted PIN‐block (Pin) and key serial number (KeySerialNumber). The request must have neither piece of data for the transaction to process as PIN‐less. See Swiped PIN‐less Debit Sale on page 91 for a detailed example.
If you send both the Pin and KeySerialNumber, the transaction processes as a standard PIN‐based debit transaction. Sending only one field or the other generates an error.
Phone & Internet PIN-less Transactions Transactions with phone or Internet origins require additional consideration when processing with Concord.
The payment server checks the RegisterNum passed in the request against the register number settings in the merchant account. When it locates a match, the server sends Concord the terminal ID configured to correspond to that register number.
If the payment server doesn’t send a terminal ID, the field assumes whatever value the processor has set as default (usually “01”). If you support phone‐originating (VRU) transactions, you must create a separate terminal ID field in the merchant account registers and submit it in your requests.
If the merchant wants to concurrently support transactions originating from the Internet and the phone, the value for the terminal ID must be able to differentiate between the two. For example, you could specify a terminal ID value of “01” for Internet transactions and “02” for phone transactions, and transmit the corresponding RegisterNum in the requests.
4.6.2.2. Fuel Purchases
Concord (EFSNet) supports fuel purchases on standard debit cards using the Items element in the ExtData.
The Items tag holds one or more Item elements that contain details of each item from an invoice. Within each Item element are several description tags, including Category. In order to mark a transaction for fuel processing, at least one Item in a request must have a Category value of Fuel. See Swiped Debit Fuel Sale on page 93 for a detailed example.
90
4.6.2.3. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.6.2.3.1. Swiped PIN-less Debit Sale
The following example processes a swiped PIN‐less debit Sale transaction. Note that in order to be processed as a PIN‐less transaction, both the PIN‐block and key serial number must be omitted.
The following example processes a swiped debit card Force transaction as a fuel purchase using the authorization obtained in Swiped Debit Auth above. Because this is a fuel purchase, the ExtData includes one Item with a Category value of Fuel.
Parameter Value
UserName test
Password 123
TransType Force
CardNum 4011190070070071
ExpDate 0606
MagData 4011190070070071=060600199100
NameOnCard John Doe
Amount 50.00
PNRef 39549
Pin A0C98099B1341075
92
Parameter Value ExtData <KeySerialNumber>1234567890000343</KeySerialNumber><Items><It
The following example processes a swiped debit Sale transaction as a fuel purchase. In order to process as a fuel transaction, at least one Item element within the Items tag has a Category value of Fuel.
This section details requirements and features specific to CredoRax. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.7.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with CredoRax.
Parameter Description
ExtData <PNRef>PNRef</PNRef> PNRef of transaction you’re targeting for information.
This section details requirements and features specific to Echo/Intuit. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.8.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Echo/Intuit.
Parameter
Description
ExtData <AccType>AccType</AccType>
<ID1>ID1</ID1>
<ID1_Type>ID_Type1</ID1_Type>
<ACH_Payment_Type>Type</ACH_Payment_Type>
<Cust_Bank>Bank</Cust_Bank>
4.9. Elavon/Nova
This section details requirements and features specific to Elavon/Nova. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
96
4.9.1. ProcessCheck
The following table contains additional information for using the ProcessCheckWeb service operation with Elavon/Nova.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
4.9.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Elavon/Nova.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
The following table contains additional information for using the ProcessDebitCard Web service operation with Elavon/Nova.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
The following table contains additional information for using the ProcessEBTCard Web service operation with Elavon/Nova.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
The following table contains additional information for using the ProcessGiftCard Web service operation with Elavon/Nova.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
4.10. FastCheck/Cyclone (GETI)
This section details requirements and features specific to FastCheck/Cyclone (GETI). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.10.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FastCheck/Cyclone (GETI).
Parameter Description TransType Force: Must replace an existing declined transaction.
98
Parameter Description
SS Last 4 digits of check holder’s social security number.
Terminals that require identity verification only require
one identifying element, accepting the social security
number or date of birth. If you pass both parameters,
the server drops DOB and uses SS.
DOB Check holder’s date of birth. Only the year is necessary, and it can be
parsed from the following formats: YYYY, MMDDYY, MMDDYYYY.
Terminals that require identity verification only require
one identifying element, accepting the social security
number or date of birth. If you pass both parameters,
the server drops DOB and uses SS.
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
Indicates if the customer accepts the terms of the Electronic Check
Acceptance (ECA) transaction. Valid values are: T, F.
<IP>IP</IP> In nnn.nnn.nnn.nnn format.
<CheckImageFormat>Format</CheckImageFormat> Indicates the
image data format of CheckImageFront and CheckImageBack. Valid
values are: Receipt1 and Base64. For more information, please see
Uploading Check Image at Transaction Time on page 100.
<CheckImageFront>Front</CheckImageFront> For more
information, please see Uploading Check Image at Transaction
99
Parameter
Description
Time on page 100.
<CheckImageBack>Back</CheckImageBack> Image data for the back of the check. For more information, please see Uploading Check Image at Transaction Time on page 100.
4.10.2. Uploading Check Image at Transaction Time
PathwayLINK supports uploading a check image at the time of a Sale, Auth, or Force transaction. To perform an image upload, the ExtData of the transaction request must contain the format of the image data (CheckImageData), the image data for the front of the check (CheckImageFront), and the image data for the back of the check (CheckImageBack).
The two supported data formats for the check image are:
Receipt1: A tiff image that is zipped and Base64‐encoded. This is the same format used in
ProcessSignature. Tiff_Img: A Base64‐encoded tiff image.
If an approved transaction has image data in Tiff_Img format, fore saving it to the database to conserve size. This, essentially, converts the data into Receipt1 format.
4.10.2.1. Supported SEC Types
FastCheck/Cyclone (GETI) supports the following SEC types:
Point‐of‐Purchase Entry (POP): Supported transactions: Sale, Auth. Supported industries: Retail. Image upload not required.
Internet Initiated Entry (WEB): Supported transactions: Sale. Telephone Initiated Entry (TEL): Supported transactions: Sale. Prearranged Payment and Deposit Entry (PPD): Recurring billing personal checks.
Supported transactions: Sale. Corporate Credit or Debit(CCD): Recurring billing for corporate checks. Supported
transactions: Sale.
4.10.3. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with FastCheck/Cyclone (GETI).
Parameter Description TransType Deactivate: Not supported.
100
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CardType>CardType</CardType> Required to process an eCertificate issuance. Valid value: Certificate.
<ServerID>ServerID<ServerID> Required for all transactions. Unique server identification number. This parameter removes invalid characters. See XML Character Removal on page 172 for more details.
4.10.3.1. eCertificates
FastCheck/Cyclone (GETI) supports eCertificate processing. An eCertificate is a gift card that lacks a physical card. eCertificate transactions are exactly the same as normal gift transactions with the exception of issuance.
To issue an eCertificate, run an Issue transaction and pass CardType with a value of Certificate in the ExtData. A successful issuance returns a new gift certificate number in the ExtData under CardNum. eCertificates display in the reports and database like normal gift issues.
4.10.4. Response Values
The following table contains descriptions of response values specific to FastCheck/Cyclone (GETI).
Parameter Description
ExtData <ReceiptData> Indicates data that should print on the receipt. <Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
This section details requirements and features specific to FirstData BuyPass. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
101
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.11.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FirstData BuyPass.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
4.11.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with FirstData BuyPass.
Parameter
Description
ExtData <CustCode>CustomerCode</CustCode> Not supported.
<TaxAmt>TaxAmt</TaxAmt> Required for purchasing cards.
<PONum>PONum</PONum> Required for purchasing cards.
FirstData BuyPass supports PIN‐less debit processing using PIN‐less and its nested elements.
To perform a PIN‐less debit transaction, the ExtData of your request must contain the PhoneNum, AccountNum, ID, and Origin elements within the PIN‐less tag. Refer to the table above for more details.
4.11.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with FirstData BuyPass.
Parameter Description ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
4.11.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with FirstData BuyPass.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
104
4.11.6. Response Values
The following table contains descriptions of response values specific to FirstData BuyPass.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
<BalanceAmount>BalanceAmount</BalanceAmount> Remaining balance on the account.
</ReceiptData>
4.12. FirstData Nashville
This section details requirements and features specific to FirstData Nashville. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.12.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FirstData Nashville.
Parameter Description ExtData <BillPayment>BillPayment</BillPayment> Indicates if a transaction is a
utility bill payment. Valid values are: T, F. Only supported for Sale and
RepeatSale transactions.
4.12.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with FirstData Nashville.
Parameter
Description
TransType Adjustment: Modifies the existing TipAmt, TaxAmt, or PONum for an
original sale.
105
Parameter
Description
ExtData <BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for
Sale and RepeatSale transactions.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
4.12.3. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with FirstData Nashville.
Parameter Description
ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
4.12.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with FirstData Nashville.
Parameter Description
ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for
Sale and RepeatSale transactions.
106
4.12.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with FirstData Nashville.
Parameter
Description
ExtData <BillPayment>BillPayment</BillPayment> Indicates if a transaction is a
utility bill payment. Valid values are: T, F. Only supported for Sale and
RepeatSale transactions.
4.12.6. Response Values
The following table contains descriptions of response values specific to FirstData Nashville.
Parameter
Description
ExtData <ReceiptData> Indicates data that should print on the receipt.
This section details requirements and features specific to FirstData North. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
107
4.13.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FirstData North.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a
transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
4.13.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with FirstData North.
Parameter
Description
TransType Reversal: Performs a manual full reversal on a credit sale or repeat
sale. Reversals must process within 24 hours of the original
transaction.
To perform a Reversal for a transaction that had partial
authorzation, you must pass the IIAS_Indicator element
in the ExtData. See Credit Partial Reversal with IIAS on
page 110 for a detailed example.
Adjustment: Modifies the existing TipAmt, TaxAmt, or PONum for
an original sale.
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None,
<BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for
Sale and RepeatSale transactions.
<IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the
current transaction is authorized by an Inventory Information
108
Parameter
Description
Approval System. Industry must be Retail, and card issuer must be
Visa orMasterCard. Industry must be Retail, and card issuer must
be Visa or MasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
4.13.2.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.13.2.1.1. Swiped Credit Sale with IIAS
The following example processes a swiped credit Sale transaction with IIAS data.
</Response> 4.13.2.1.3. Credit Partial Reversal with IIAS
The following example processes a swiped credit partial Reversal transaction with IIAS data. Partial reversals have the Amount field set to the portion of the original authorized amount to be reversed.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
4.13.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with FirstData North.
Parameter
Description
ExtData <IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the
current transaction is authorized by an Inventory Information
Approval System. Industry must be Retail, and card issuer must be
Visa or MasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None,
<BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for
Sale and RepeatSale transactions.
4.13.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with FirstData North.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
112
4.13.6. Response Values
The following table contains descriptions of response values specific to FirstData North.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Partial_Reversal_Flag> Flag</Partial_Reversal_Flag> Indicates that transaction processed as a partial reversal. Valid values: T.
<Total_Amount>Total_Amount</Total_Amount> Total amount authorized.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved. <BalanceAmount>BalanceAmount</BalanceAmount> Remaining balance on the account.
</ReceiptData>
4.14. FirstData Omaha
This section details requirements and features specific to FirstData Omaha. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.14.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FirstData Omaha.
Parameter Description ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID
is sent with the request. Valid values are: None, NotSubmitted,
Submitted, Illegible, NotPresent [on card].
113
4.14.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with FirstData Omaha.
Parameter Description TransType Adjustment: Modifies the existing TipAmt, TaxAmt, or PONum for an
original sale.
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.14.3. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with FirstData Omaha.
Parameter
Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID
is sent with the request. Valid values are: None, NotSubmitted,
Submitted, Illegible, NotPresent [on card].
4.14.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with FirstData Omaha.
Parameter Description ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID
is sent with the request. Valid values are: None, NotSubmitted,
Submitted, Illegible, NotPresent [on card].
4.14.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with FirstData Omaha.
Parameter Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
114
4.14.6. Response Values
The following table contains descriptions of response values specific to FirstData Omaha.
Parameter
Description
ExtData <ReceiptData> Indicates data that should print on the receipt.
4.15. FirstData South
This section details requirements and features specific to FirstData South. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.15.1. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with FirstData South.
Parameter
Description
TransType Adjustment: Modifies the existing TipAmt for an original sale.
4.16. FirstData Telecheck
This section details requirements and features specific to FirstData Telecheck. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.16.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with FirstData Telecheck.
Parameter Description
TransType Sale: Not supported.
Auth: You must follow‐up an Auth with a Force to approve or decline the transaction. The Force must contain CustECAApproval within the ExtData.
115
Parameter Description
ExtData <Phone>Phone</Phone> Required for Auth transactions in eCommerce.
<BillToStreet>BillToStreet</BillToStreet> Required for Auth transactions in eCommerce.
<BillToStreet2>BillToStreet2</BillToStreet2> Required for Auth transactions in eCommerce.
<BillToCity>BillToCity</BillToCity> Required for Auth transactions in eCommerce.
<BillToPostalCode>BillToPostalCode</BillToPostalCode> Required for Auth transactions in eCommerce.
<EMail>EMail</EMail> Required for Auth transactions in eCommerce.
<IP>IP</IP> Required for Auth transactions in eCommerce. In nnn.nnn.nnn.nnn format.
<PNRef>PNRef</PNRef> Required for Force transactions in eCommerce.
<CustECAApproval>CustECAApproval</CustECAApproval> Required for Force transactions in eCommerce. Indicates if the customer accepts the terms of the Electronic Check Acceptance (ECA) transaction. Valid values are: T, F.
This section details requirements and features specific to GiveX. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.17.1. Additional Extended Data
The following table contains additional extended data that GiveX supports.
Parameter Description
ExtData <Unit>Unit</Unit>
<PromoCode>PromoCode</PromoCode>
4.18. Global East
This section details requirements and features specific to Global East. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
117
4.18.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with Global East.
Parameter
Description
TransType KeyChangeRequest: Contacts the Global host to get a new key sent to
the PIN pad in use. You would perform this request when the PIN pad is
initialized for the first time or after a necessary reboot.
ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the
payment server should query the processor for information for the
current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left
unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.18.2. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Global East.
Parameter Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown.
</AuthenticationCapability>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
118
4.18.3. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Global East.
Parameter Description
TransType Reversal: Performs a manual full reversal on a credit sale or repeat sale. A reversal transaction acts as a void host and must be processed within the open batch time period. Support for all industries and card issuers.
Adjustment: Modifies the existing TipAmt or TotalAmt for an original sale.
ExtData <CustCode>CustomerCode</CustCode> If CustCode is left blank, Global Payments East defaults to PONum for level 2 data.
<AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
<Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown).
</Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
Global East supports PIN‐less processing for qualifying debit transactions.
120
To perform a PIN‐less debit transaction, your request requires all of the same information in a typical PIN‐based transaction except for the encrypted PIN‐block (Pin) and key serial number (KeySerialNumber). The request must have neither piece of data for the transaction to process as PIN‐less. See Swiped PIN‐less Debit Sale on page 121 for a detailed example.
If you send both the Pin and KeySerialNumber, the transaction processes as a standard PIN‐based debit transaction. Sending only one field or the other generates an error.
4.18.4.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.18.4.2.1. Swiped PIN-less Debit Sale
The following example processes a swiped PIN‐less debit Sale transaction. In order to process as a PIN‐less transaction, both the PIN‐block (Pin) and Key Serial Number (KeySerialNumber) are omitted.
The following table contains additional information for using the ProcessEBTCard Web service operation with Global East.
Parameter Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown.
</AuthenticationCapability>
<IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the current transaction is authorized by an Inventory Information Approval System. Industry must be Retail, and card issuer must be Visa or MasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F..
<Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown).
</Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
The following table contains additional information for using the ProcessGiftCard Web service operation with Global East.
Parameter Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown.
</AuthenticationCapability>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
4.18.7. Response Values
The following table contains descriptions of response values specific to Global East.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Partial_Reversal_Flag>Partial_Reversal_Flag</Partial_Reversal_F lag> Indicates that transaction processed as a partial reversal. Valid values: T.
<Total_Amount>Total_Amount</Total_Amount> Total amount authorized.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
</ReceiptData>
123
4.19. Global Interac (Canada)
This section details requirements and features specific to Global Interac (Canada). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.19.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with Global Interac (Canada).
Parameter Description
TransType Initialize: Returns the merchant account setup information (e.g., Partner Number, Merchant ID, credit card type, etc.).
ExtData <TID>TID</TID> Required for the KeyChangeRequest TransType. Terminal Identification Number derived from the PIN pad used in the
transaction.
4.19.2. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with Global Interac (Canada).
Parameter Description
TransType AddReversal: If the host sends a response for information validation, and the customer’s PIN input is invalid, this TransType reverses the
transaction sent to the host.
PNRef Required for AddReversal TransType.
ExtData <MAC> Required. Instead of using a KeySerialNumber, Global Interac (Canada) uses MAC tags to facilitate the transaction. See Swiped Debit Sale on page 126 for a detailed example. <TID>TID</TID Required for the AddReversal TransType. Terminal Identification Number derived from the PIN pad used in the transaction.
<PSN>PSN</PSN> Required. The Point‐of‐Sale sequence number. Maintained by the SmartPayments Client application, valid values are: 001–999.
<Value>Value</Value> Required. MAC value obtained from the PIN pad device.
124
Parameter
Description
<Language>Language</Language> Required. Sets the language
used for the transaction. Valid values are: English, French.
</MAC>
<AccountType>AccountType</AccountType> Required for AddReversal. Valid values are: Checking, Saving.
4.19.2.1. PIN-less Debit Transactions
Global Payments East supports PIN‐less processing for qualifying debit transactions.
To perform a PIN‐less debit transaction, your request requires all of the same information in a typical PIN‐based transaction except for the encrypted PIN‐block (Pin) and key serial number (KeySerialNumber). The request must have neither piece of data for the transaction to process as PIN‐less. See Swiped PIN‐less Debit Sale on page 121 for a detailed example.
If you send both the Pin and KeySerialNumber, the transaction processes as a standard PIN‐based debit transaction. Sending only one field or the other generates an error.
4.19.2.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.19.2.2.1. Swiped PIN-less Debit Sale
The following example processes a swiped PIN‐less debit Sale transaction. In order to process as a PIN‐less transaction, both the PIN‐block (Pin) and Key Serial Number (KeySerialNumber) are omitted.
The example data below illustrates a swiped debit Sale transaction. Instead of the U.S. standard, KeySerialNumber, Canadian debit uses MAC and its child elements to facilitate the transaction.
This section details requirements and features specific to Heartland Payments. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.20.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Heartland Payments.
Parameter Description ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
127
4.20.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Heartland Payments.
Parameter Description
ExtData <Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown). </Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
4.20.3. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with Heartland Payments.
Parameter
Description
ExtData <Presentation> Indicates card presence in a transaction.
are: True (card present), False (card not present or unknown).
</Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
4.20.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with Heartland Payments.
Parameter Description
ExtData <Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown).
</Presentation>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
128
4.20.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Heartland Payments.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
4.21. IntegraPay
This section details requirements and features specific to IntegraPay. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.21.1. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with IntegraPay.
Parameter Description
TransType Adjustment: Not supported.
Auth: Not supported.
Return: Must be associated with a Sale (no blind returns).
Void: Not supported.
Force: Not supported.
RepeatSale: Not supported.
NameOnCard Required for Sale TransType.
4.21.2. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with IntegraPay.
Parameter Description TransType Return: Must be associated with a Sale (no blind returns).
NameOnCard Required for Sale TransType.
129
4.22. Litle
This section details requirements and features specific to Litle. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.22.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Litle.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,
MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
4.22.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Litle.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<Authentication> Required to process a transaction using Visa’s
Verified By Visa and MasterCard’s SecureCode programs.
<XID>AuthenticationID</XID> The Unique Transaction Identifier
<TrustAttempt>T</TrustAttempt> Indicates Verified By Visa or
SecureCode attempted, but there was no XID or UCAF available
for the transaction. Valid values are: T, F.
</Authentication>
4.22.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with Litle.
Parameter Description ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
4.22.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Litle.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for
the payment information were obtained. Valid values are: UNKNOWN,
MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
131
4.23. Mercury Payment Systems
This section details requirements and features specific to Mercury Payment Systems. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.23.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Mercury Payment Systems.
Parameter Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted,
Submitted, Illegible, NotPresent [on card].
4.23.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Mercury Payment Systems.
Parameter
Description
TransType Adjustment: Modifies the existing TipAmt or TotalAmt for an original
sale.
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None,
The following table contains additional information for using the ProcessDebitCard Web service operation with Mercury Payment Systems.
Parameter
Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID
is sent with the request. Valid values are: None, NotSubmitted,
Submitted, Illegible, NotPresent [on card].
132
4.23.4. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with Mercury Payment Systems.
Parameter Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the current transaction is authorized by an Inventory Information Approval System. Industry must be Retail, and card issuer must be Visa orMasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
4.23.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Mercury Payment Systems.
Parameter Description
ExtData <CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<GiftCVV>GiftCVV</GiftCVV> Indicates if a CVV2/CVC2/CID is sent
with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.23.6. Additional Extended Data
The following table contains additional extended data that Mercury Payment Systems supports.
The following table contains descriptions of response values specific to Mercury Payment Systems.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
</ReceiptData>
4.24. Paymentech (Tampa)
This section details requirements and features specific to Paymentech (Tampa). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.24.1. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with Paymentec (Tampa).
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.24.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Paymentec (Tampa).
Parameter
Description
TransType Adjustment: Modifies the existing TipAmt for an original sale.
134
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown).
</Presentation>
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
4.24.3. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with Paymentec (Tampa).
Parameter Description
ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, and PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None,
are: True (card present), False (card not present or unknown).
</Presentation>
4.24.5. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with Paymentec (Tampa).
Parameter Description
TransType Force: Places a transaction unprocessed by the payment server into the current batch (ForceAuth).
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, and PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
136
4.24.5.1. Gift ForceAuth Transactions
ForceAuth Element
You may place a previously authorized Redeem, Reload, and Activate transaction into the current batch by running the respective transaction with the ForceAuth and AuthCode elements in the ExtData. See Manual Gift Force (ForceAuth Redeem) on page 138 and Manual Gift Force (ForceAuth Reload) on page 138 for detailed examples.
Force TransType
There is an additional method of placing a previously authorized Redeem transaction into the current batch. Using the Force TransType, send a request with the AuthCode of the original transaction within the ExtData. See Swiped Gift Force on page 137 for a detailed example.
4.24.5.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.24.5.2.1. Swiped Gift Force
The following example places a previously authorized swiped Redeem transaction into the current batch by using the Force TransType and sending the AuthCode in the ExtData.
The following table contains descriptions of response values specific to Paymantec (Tampa).
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
<BalanceAmount>BalanceAmount</BalanceAmount> Remaining balance on the account.
</ReceiptData>
4.25. Planet Payment
This section details requirements and features specific to Planet Payment. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
139
4.25.1. ProcessDCCLookup
Planet Payment supports Dynamic Currency Conversion (DCC) with ProcessDCCLookup. This Web service uses currency exchange rates to tell the merchant the equivalent transaction amount to charge in the cardholder’s currency. The URL to access this service is:
DCC determines the cardholder’s currency code from the card number and uses the merchant’s configuration when the MID registers with the host. Using the two currency codes and the original amount, ProcessDCCLookup returns the exchange rate between the two currencies and the transaction amount in the cardholder’s currency.
The following table contains parameter descriptions.
Parameter Value
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
CardNum Required. Credit card number used to process the transaction.
ExpDate Required. Credit card’s expiration date in MMYY format.
Amount Required. The total transaction amount.
4.25.1.1. Examples
The following examples show different functions available with this Web service. Change the credentials and payment information fields when running test transactions.
4.25.1.1.1. DCC Lookup
The following example performs a DCC lookup from Yen to USD. To see a follow‐on transaction using DCC in a credit sale, see Credit Sale with DCC on page 144.
Planet Payments supports Multi‐Currency Pricing (MCP) through ProcessMCPLookup. This Web servies uses currency exchange rates to tell the merchant the equivalent amount of a transaction in a foreign currency. URL to access this service is:
Using the the currency code of the desired foreign currency (FromCurrencyCode) and the merchant’s currency code (determined from merchant configuration when MID regisers with the host), MCP returns the exchange rate between the two currencies and the transaction amount in the cardholder’s currency.
A merchant would use this form of currency conversion to set prices ahead of time for specific foreign currencies.
The following table contains parameter descriptions.
Parameter Value
UserName Required. Username assigned in the payment server.
Password Required. Password for the username assigned in the payment server.
Amount Required. The total transaction amount.
FromCurrencyCode Required. The cardholder’s currency code.
4.25.2.1. Supported Currency Codes
The following table displays currency codes currently supported by Planet Payments.
Code
Currency Code
Currency
124 Canadian Dollar 422 Lebanese Pound
141
360 Indonesian Rupiah 826 Pound Sterling
392 Yen 840 United States Dollar
414 Kuwaiti Dinar 978 Euro
4.25.2.2. Examples
The following examples show different functions available with this Web service. Change the credentials and payment information fields when running test transactions.
4.25.2.2.1. MCP Lookup
The following example performs an MCP lookup from Yen to USD. To see a follow‐on transaction using MCP in a credit sale, see Credit Sale with MCP on page 145.
Required for MCP processing. Cardholder’s currency code.
<TransAmount>TransAmount</TransAmount> Required for
MCP processing. The transaction amount in the cardholder’s
currency.
When performing an MCP Sale or Auth, you must set the
Amount parameter to 0. The payment server will
populate the proper sale amount after the conversion.
</Currency>
4.25.4.1. Currency Conversion
Planet Payment supports two methods of currency conversion for Sale and Auth transactions using the Currency tag and its child elements.
Direct Currency Conversion (DCC) takes the sale amount in the merchant’s currency and converts it to the cardholder’s currency. DCC examines the card number to determine the cardholder’s local currency. To perform a DCC Sale or Auth transaction, you must pass the Currency and Type elements in the ExtData.
Multi‐Currency Processing (MCP) takes the sale amount in the cardholder’s currency and converts it to the merchant’s currency. MCP uses the cardholder’s currency code to convert the transaction amount back to the merchant’s currency. To perform an MCP Sale or Auth transaction, you must pass the Currency, Type, FromCurrencyCode, and TransAmount elements in the ExtData.
4.25.4.2. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.25.4.2.1. Credit Sale with DCC
The following example processes a DCC credit Sale of 15.00 USD for a merchant who accepts the 392 currency code (Yen).
The following example processes an MCP credit Sale. In this example, the cardholder currency is 392 (Yen). This transaction converts 564 Yen to $6.88USD and processes a sale. PathwayLINK returns the conversion rate and final transaction amount in the merchant's currency.
The payment server processes the value in the standard Amount parameter in the merchant's currency format. This can cause decimal errors on final reports because not all currencies support decimals (e.g., Yen). To avoid this issue, pass 0 in Amount and pass the amount in the cardholder currency using the TransAmount field within ExtData.
This section details requirements and features specific to Profit Stars. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.26.1. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Profit Stars.
Parameter Description
ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
4.26.2. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with Profit Stars.
Parameter Description ExtData <Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
4.26.3. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with Profit Stars.
Parameter
Description
ExtData <IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the
current transaction is authorized by an Inventory Information
Approval System. Industry must be Retail, and card issuer must be
Visa orMasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
147
4.27. TSYS (Host)
This section details requirements and features specific to TSYS (Host). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.27.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with TSYS (Host).
Parameter
Description
ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the
payment server should query the processor for information for the
current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.27.2. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with TSYS (Host).
Parameter
Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate
<BillPayment>BillPayment</BillPayment> Indicates if a
transaction is a utility bill payment. Valid values are: T, F. Only
supported for Sale and RepeatSale transactions.
4.27.4. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with TSYS (Host).
Parameter Description
TransType Reversal: Performs a manual full reversal on a debit sale or repeat sale.
Reversals must process within 2 hours of the original transaction.
Supported industries: Retail, Restaurant. Support for all card issuers.
Manual debit reversals require the CardNum, ExpDate,
and PNRef of the original sale transaction.
149
Parameter Description
ExtData <Presentation> Indicates card presence in a transaction. <CardPresent>CardPresent Value</CardPresent> Valid values are: True (card present), False (card not present or unknown).
</Presentation>
<AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown. </AuthenticationCapability>
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
4.27.4.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.27.4.1.1. Manual Debit Reversal
The following example processes a manual debit Reversal transaction. For manual debit reversals, TSYS requires the CardNum, ExpDate, and original sale PNRef.
For illustrative purposes, this example includes the original sale transaction.
Original Sale Transaction
Parameter Value UserName test
Password 123
TransType Sale
CardNum 9999999800002773
ExpDate 0509
NameOnCard John Smith
Amount 20.00
Pin 402ABE473425535E
150
Parameter Value ExtData <KeySerialNumber>0123456780269000008</KeySerialNumber>
<BillPayment>BillPayment</BillPayment> Indicates if a
transaction is a utility bill payment. Valid values are: T, F. Only
supported for Sale and RepeatSale transactions.
4.27.6. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with TSYS (Host).
Parameter Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown.
</AuthenticationCapability>
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
152
4.27.7. Additional Extended Data
The following table contains additional extended data that TSYS (Host) supports.
This section details requirements and features specific to TSYS (Terminal). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.28.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with TSYS (Terminal).
Parameter
Description
ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the
payment server should query the processor for information for the
current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.28.2. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with TSYS (Terminal).
Parameter
Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
156
4.28.4.1. Examples
The following examples show different functions available with this Web service operation. Change the credentials and payment information fields when running test transactions.
4.28.4.1.1. Manual Debit Reversal
The following example processes a manual debit Reversal transaction. For manual debit reversals, TSYS requires the CardNum, ExpDate, and original sale PNRef.
For illustrative purposes, this example includes the original sale transaction.
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction is a utility bill payment. Valid values are: T, F. Only supported for Sale and RepeatSale transactions.
<IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the current transaction is authorized by an Inventory Information Approval System. Industry must be Retail, and card issuer must be Visa or MasterCard. Valid values are: T, F.
158
Parameter
Description
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial authorization for available funds. Valid values are: T, F.
4.28.6. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with TSYS (Terminal).
Parameter
Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate
<EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<BillPayment>BillPayment</BillPayment> Indicates if a transaction
is a utility bill payment. Valid values are: T, F. Only supported for
Sale and RepeatSale transactions.
4.28.7. Response Values
The following table contains descriptions of response values specific to FirstData Nashville.
Parameter Description ExtData <ReceiptData> Indicates data that should print on the receipt. <Partial_Reversal_Flag>Partial_Reversal_Flag</Partial_Reversal_F lag> Indicates that transaction processed as a partial reversal. Valid values: T.
<Total_Amount>Total_Amount</Total_Amount> Total amount authorized.
<Requested_Amt>Requested_Amt</Requested_Amt> Total amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount approved.
<BalanceAmount>BalanceAmount</BalanceAmount> Remaining balance on the account.
</ReceiptData>
159
4.29. Valutec
This section details requirements and features specific to Valuetec. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.29.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with Valuetec.
Parameter
Description
ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the
payment server should query the processor for information for the
current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.30. Vantiv (Cincinnati)
This section details requirements and features specific to Vantiv (Cincinnati). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.30.1. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Vantiv (Cincinnati).
Parameter
Description
TransType Auth: Not supported in Retail or Restaurant.
160
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.30.2. ProcessDebitCard
The following table contains additional information for using the ProcessDebitCard Web service operation with Vantiv (Cincinnati).
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.30.3. ProcessEBTCard
The following table contains additional information for using the ProcessEBTCard Web service operation with Vantiv (Cincinnati).
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are:
UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None,
The following table contains additional information for using the ProcessGiftCard Web service operation with Vantiv (Cincinnati).
Vantiv does not support Gift transactions in eCommerce.
Parameter Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN,MANUAL,MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
4.30.5. ProcessLoyaltyCard
Vantiv does not support Loyalty transactions in eCommerce.
4.30.6. Response Values
The following table contains descriptions of response values specific to Vantiv (Cincinnati).
Parameter
Description
ExtData <ReceiptData> Indicates data that should print on the receipt.
<Requested_Amt>Requested_Amt</Requested_Amt> Total
amount requested.
<Approved_Amt>Approved_Amt</Approved_Amt> Total amount
This section details requirements and features specific to Vantiv (St. Petersburg). If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
162
4.31.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with Vantiv (St. Petersburg).
Parameter Description ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the payment server should query the processor for information for the current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left
unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.31.2. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with Vantiv (St. Petersburg).
Parameter
Description
TransType Auth: Not supported in Retail or Restaurant.
Reversal: Performs a manual full reversal on a credit sale or repeat
sale. A reversal transaction acts as a void host and must be
processed within the open batch time period. Support for all
industries and card issuers.
Adjustment: Modifies the existing TipAmt or TotalAmt for an
original sale.
ExtData <Presentation> Indicates card presence in a transaction.
This section details requirements and features specific to WorldPay. If you have any questions or need additional information regarding this processor, please contact our integration specialists at [email protected].
Unless otherwise specified, assume that all parameters have the same requirements as specified in main document.
4.32.1. GetInfo
The following table contains additional information for using the GetInfo Web service operation with Global East.
Parameter Description TransType KeyChangeRequest: Contacts the Global host to get a new key sent to
the PIN pad in use. You would perform this request when the PIN pad is
initialized for the first time or after a necessary reboot.
166
Parameter Description ExtData <BatchSequenceNum>Number</BatchSequenceNum> Indicates if the payment server should query the processor for information for the current or a previous batch. Valid values are:
0: Current open batch (default value if BatchSequenceNum is left
unspecified in ExtData).
1: Previous batch.
2: The batch before the previous batch specified with the value 1.
N: And so on…
4.32.2. ProcessCheck
The following table contains additional information for using the ProcessCheck Web service operation with WorldPay.
Parameter
Description
ExtData <EntryMode>EntryMode</EntryMode> Indicates how the values
for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<ServiceType>ServiceType</ServiceType> Transaction override for
check transactions. Not currently exposed. Valid values are: None, Verification, Guarantee, Conversion.
4.32.3. ProcessCreditCard
The following table contains additional information for using the ProcessCreditCard Web service operation with WorldPay.
Parameter Description TransType Reversal: Performs a manual full reversal on a credit sale or repeat
sale. A reversal transaction acts as a void host and must be processed
within the open batch time period. Support for all industries and card
issuers.
ExtData <Authentication> Required to process a transaction using Visa’s Verified By Visa and MasterCard’s SecureCode programs.
<XID>AuthenticationID</XID> The Unique Transaction Identifier (applies to Verified By Visa).
<TrustAttempt>T</TrustAttempt> Indicates Verified By Visa or
SecureCode attempted, but there was no XID or UCAF available
for the transaction. Valid values are: T, F.
</Authentication>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are: UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a
CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
<IIAS_Indicator>IIAS_Indicator</IIAS_Indicator> Indicates if the
current transaction is authorized by an Inventory Information
Approval System. Industry must be Retail, and card issuer must be
Visa or MasterCard. Valid values are: T, F.
<Partial_Indicator>Partial_Indicator</Partial_Indicator> When
enabled, instructs the host to process the transaction as a partial
authorization for available funds. Valid values are: T, F.
4.32.6. ProcessGiftCard
The following table contains additional information for using the ProcessGiftCard Web service operation with WorldPay.
Parameter Description
ExtData <AuthenticationCapability> Sent by the POS application to indicate if a PIN pad is connected to the POS system. <PINCapability>PINCapability</PINCapability> PIN capability. Valid values are: Capable, Incapable, Inoperative, Unknown.
</AuthenticationCapability>
<EntryMode>EntryMode</EntryMode> Indicates how the values for the payment information were obtained. Valid values are:
UNKNOWN, MANUAL, MAGNETICSTRIPE, ICC, PROXIMITY.
<CVPresence>CVPresence</CVPresence> Indicates if a CVV2/CVC2/CID is sent with the request. Valid values are: None, NotSubmitted, Submitted, Illegible, NotPresent [on card].
170
A. Appendix
A.1. Valid Input Characters
The following table displays all characters accepted by the payment server. All other characters may yield undesirable results.
DEC HEX
Character DEC HEX Character DEC HEX Character
32 20 Space 63 3F ? 96 60 `
33 21 ! 64 40 @ 97 61 a
34 22 " 65 41 A 98 62 b
35 23 # 66 42 B 99 63 c
36 24 $ 67 43 C 100 64 d
37 25 % 68 44 D 101 65 e
38 26 & 69 45 E 102 66 f
39 27 ' 70 46 F 103 67 g
40 28 ( 71 47 G 104 68 h
41 29 ) 72 48 H 105 69 i
42 2A * 73 49 I 106 6A j
43 2B + 74 4A J 107 6B k
44 2C , 75 4B K 108 6C l
45 2D ‐ 76 4C L 109 6D m
46 2E . 77 4D M 110 6E n
47 2F / 78 4E N 111 6F o
48 30 0 79 4F O 112 70 p
49 31 1 80 50 P 113 71 q
50 32 2 81 51 Q 114 72 r
51 33 3 82 52 R 115 73 s
52 34 4 83 53 S 116 74 t
53 35 5 84 54 T 117 75 u
54 36 6 85 55 U 118 76 v
55 37 7 86 56 V 119 77 w
171
DEC HEX
Character DEC HEX Character DEC HEX Character
56 38 8 87 57 W 120 78 x
57 39 9 88 58 X 121 79 y
58 3A : 89 59 Y 122 7A z
59 3B ; 90 5A Z 123 7B {
60 3C < 92 5C \ 124 7C |
61 3D = 94 5E ^ 125 7D }
62 3E > 95 5F _ 126 7E ~
A.2. XML Character Removal
The following table displays all acceptable characters that must be removed by the payment server before submitting information to the Web service operations. This character removal ensures that the payment servers’ internal XML parsers can properly read the information of the Web service operation.
Many XML parsers encode these characters for you. In that case, the characters will not be converted back to their proper values by the payment server; they will be taken literally. Additionally, if you pass the encoded character through an input parameter that removes the characters listed in the table below, then certain characters may be removed (see Examples below).
If you are not using a parser, or if the parser does not handle this encoding, then the characters in the table listed below may still be removed, depending on the input parameter for the Web service operation you are using.
Character XML Parser Encoding < <
> >
& &
' '
" "
Examples
The following examples show how characters would be removed if the data passes through the NameOnCard parameter of the ProcessCreditCard operation.
Valid: John James
Invalid: John & James becomes John James
Invalid: John & James becomes John amp; James
172
A.3. Invoice Number We recommend using 10 Numeric, though any value passed will be sent to the processor. In order to take
advantage of the below table, you need to know the processor prior to sending the transaction. To fully
comply with the Invoice formatting rules of your specific processor, please contact them directly.
The chart below is meant to serve as a Processor based guideline for Invoice numbers: