Business Rules and Guidelines EVO NGTrans BCP

Business Rules and
Guidelines
EVO NGTrans (aka EVO Domestic) BCP Adaptor
Contents
Overview.................................................................................................................................................................. 3
Duplicate Transaction Detection and Processing.....................................................................................................5
PIN Debit Processing................................................................................................................................................6
EBT Processing.........................................................................................................................................................6
Required Fields for EBT Processing.......................................................................................................................6
Recurring Bill Payment Processing...........................................................................................................................7
Installment Payment Processing..............................................................................................................................7
Visa Debt Repayment Program................................................................................................................................8
Digital Wallet Processing..........................................................................................................................................8
Partial Reversal Processing.......................................................................................................................................8
3-D Secure Processing..............................................................................................................................................9
Verified By Visa (VbV/VPAS).................................................................................................................................9
MasterCard Secure Code (MCSC/UCAF)...............................................................................................................9
Multiple Partial Capture Processing.......................................................................................................................10
Verify() Processing..................................................................................................................................................10
CVV/CID Processing................................................................................................................................................11
Partial Approvals (Partial Authorization)................................................................................................................11
Purchase Card - Level 2..........................................................................................................................................11
Purchase Card – Level 3 (Line Item Detail).............................................................................................................12
Order Update Processing.......................................................................................................................................13
ReportingData/Reference Truncation....................................................................................................................13
Prepaid Card Final Balance.....................................................................................................................................13
PAN Tokenization...................................................................................................................................................13
End of Day..............................................................................................................................................................14
EMV Processing......................................................................................................................................................15
EMV Receipt Requirements................................................................................................................................15
Offline Funds Approval Receipt......................................................................................................................16

Fallback Approval Receipt..............................................................................................................................17
Offline Funds Decline Receipt.........................................................................................................................19
Making Payments a Snap* for Developers | Proprietary & Confidential 1

Signature CVM - Offline Funds Approval Receipt...........................................................................................20
Signature CVM – Online Approval Receipt.....................................................................................................21
Could not Authorize Online – Offline Funds Approval Receipt.......................................................................22
Could not Authorize Online – Offline Funds Declined Receipt........................................................................23
Authorized Online Approval Using PIN Receipt..............................................................................................24
Authorized Online Declined Receipt...............................................................................................................25
Fallback Declined Receipt...............................................................................................................................26
Fallback Declined Receipt...............................................................................................................................27
Fallback Refund Receipt.................................................................................................................................28
Offline Void Sale Receipt................................................................................................................................29
Online Void Sale Receipt.................................................................................................................................30
Fallback Void Sale Receipt..............................................................................................................................31
Retail/Restaurant Tip Amount Offline Funds Approved Receipt....................................................................32
Retail/Restaurant Tip Amount Online Funds Approved Using PIN Receipt....................................................33
Retail/Restaurant Tip Amount Offline Funds Approved Using Chip and Signature Receipt............................34
Retail/Restaurant Tip Amount Online Funds Approved Using Chip and Signature Receipt............................36
Retail/Restaurant Tip Amount Fallback Approved Receipt.............................................................................38
Response Codes.....................................................................................................................................................39

Overview
Transactions/Features Grid:
MOTO Ecomm Retail Rest
Transactions - CREDIT
AVSONLY (Verify) X X X X
AUTHONLY (Authorize) X X X X
AUTH Standard Purchase (AuthorizeAndCapture) X X X X
AUTH PreAuth Completion (Capture) X X X X
AUTH Force Post (AuthorizeAndCapture) X X X X
INCAUTH (Adjust +) N/A N/A N/A N/A
REVAUTH (Adjust -) N/A N/A N/A N/A
VOID (Undo) X X X X
RETURN (ReturnUnlinked) X X X X
RETURN (ReturnById) X X X X
BALINQ (QueryAccount) X X X X
AUTH or AUTHONLY Resubmission_Correction
X X X X
(Resubmit Correction for Partial Reversal)
AUTH Order_Update (ResubmitOrderUpdate) X X X X
Features - CREDIT
AVS X X X X
CVV2, CVC2, CID X X X X
3-D Secure N/A X N/A N/A
Adjustment Support (Partial Reversal Only) X X X X
Bill Payment - Deferred N/A N/A N/A N/A
Bill Payment - Installment X X N/A N/A
Bill Payment - Single (Visa Debt Repayment Only) X X N/A N/A
Bill Payment - Recurring X X N/A N/A
Purchase Card - Level 2 X X X N/A
Purchase Card - Extended Level 2 N/A N/A N/A N/A
Purchase Card - Level 3 X X X N/A
Purchase Card - Extended Level 3 N/A N/A N/A N/A
Soft Descriptors (Alternate Merchant Data) X X X X
Convenience Fees N/A N/A N/A N/A
IIAS – Healthcare Amounts N/A N/A N/A N/A
Canadian Merchants N/A N/A N/A N/A
Amex Enhanced AVS N/A N/A N/A N/A
Visa/MasterCard Tokenization X X N/A N/A
Secure MSR N/A N/A N/A N/A
Contactless Cards N/A N/A X X
Cash Back N/A N/A N/A N/A
Partial Approvals X X X X

Cardholder Activated Transactions (CAT) X X X X
Private Label Cards N/A N/A N/A N/A
Quasi-Cash N/A N/A N/A N/A
EMV Support with PIN N/A N/A X X
Host Capture Manual Batch Close X X X X
Visa Debt Repayment X X
Partial Shipments X X X X
Card on File Indicator X X X X
Single Authorization Multiple Partial Captures X X X X
Digital Wallet N/A X N/A N/A
Duplicate Transaction Checking X X X X
EBT Support N/A N/A X N/A
Credentials Required N/A N/A N/A N/A
Transactions - PINDEBIT
AUTH (AuthorizeAndCapture) N/A N/A X X
REVERSAL (Undo)
supported for EMV chip declines only - not N/A N/A X X
merchant initiated
RETURN (ReturnUnlinked) N/A N/A N/A N/A
RETURN (ReturnById) N/A N/A N/A N/A
BALINQ (QueryAccount) N/A N/A N/A N/A
CONF (called by adaptor) N/A N/A N/A N/A
Features - PINDEBIT
Cash Back N/A N/A X X
Partial Approvals N/A N/A X X
Scrip Devices N/A N/A N/A N/A
Visa/MasterCard Tokenization N/A N/A N/A N/A
Secure MSR N/A N/A N/A N/A
Soft Descriptors (Alternate Merchant Data) N/A N/A X X
Contactless Cards N/A N/A X X
EMV Support with PIN N/A N/A X X
Credentials Required N/A N/A N/A N/A
Transactions - EBT
AUTH (AuthorizeAndCapture) N/A N/A X N/A
REVERSAL (Undo) N/A N/A X N/A
RETURN (ReturnUnlinked) N/A N/A X N/A
BALINQ (QueryAccount) N/A N/A X N/A
Features - EBT
Food Stamp Purchase X
Food Stamp Return X
Food Stamp Voucher X
Food Stamp Voucher Return X
Cash Purchase w/Cash Back X

Soft Descriptors (Alternate Merchant Data) N/A N/A X
Transactions - BANKCARD
BATCHRELEASE (CaptureAll) X X X X
Visa, MasterCard, American Express, Discover,
Supported Card Types
JCB, Diners Club, EBT
The EVO NGTrans Domestic BCP adaptor supports Managed (host capture) processing.
Either Track 1 or Track 2 Data is supported for Credit swiped transactions. Track 2 Data is supported for PIN
Debit and EBT transactions.
As of January 2018 (.29 release) all transactions should include
BankcardTransaction/TenderData/TenderType. This field is required in order for EBT transactions to process
correctly, but all transactions should include the field due to EBT and EMV support. Credit EMV transactions with
a PIN will not process correctly unless this field is set. Rules will not be added for this requirement in order to
continue backward compatibility for existing customers that are not using EBT or EMV processing. All new
customers must be instructed to populate this field.
 Credit = “ProcessAsCredit”
 PIN Debit = “ProcessAsPinDebit”
 EBT = “ProcessAsEBT”
Duplicate Transaction Detection and

Processing
The EVO NGTrans platform will always check for duplicate transactions if they occur within 15 minutes of each
other based on:
 Same Batch Control Id (BankcardCaptureResponse/BatchId)
 Same Terminal ID (BankcardMerchantData/TerminalId)
 Same Transaction Type (Authorize, AuthorizeAndCapture, Capture)
 Same Card Number (BankcardTransaction/TenderData/CardData/PAN)
 Same Transaction Amount (BankcardTransaction/TransactionData/Amount)
 Same Original Amount
 Transaction was approved and not voided or reversed
Duplicate transactions will be declined with an error message: BankcardTransactionResponse/StatusCode will
contain “18”; BankcardTransactionResponse/StatusMessage will contain “AP DUPE”. In order to authorize
identical transactions, resubmit the declined transaction by setting
BankcardTransaction/TransactionData/TransactionCode to “Override”.
If the transaction was purposefully resent due to a timeout on the first attempt, the “AP DUPE” message lets the
merchant know that the transaction was received by the EVO host. The merchant should then query TMS or

contact customer support to get the original response. If the transaction is approved, then the original was
never received by the EVO host.
PIN Debit Processing

As of January 2018, PIN debit customers should set BankcardTransaction/TenderData/TenderType to
“ProcessAsPinDebit” due to the addition of EBT processing.
EBT Processing
EBT processing is supported by NGTrans for the Retail industry and may be used for SNAP (Supplemental
Nutrition Assistance Program or food stamp) or cash purchases. Each type of purchase must be separate, SNAP
and cash may not be combined in a single transaction.
Supported transactions are:
 AuthorizeAndCapture() – SNAP purchase / SNAP voucher purchase / cash purchase with or without cash
back
 ReturnUnlinked() – SNAP return / SNAP voucher return (cash purchase returns are handled as cash
returns by the retailer; no transaction is submitted against the card)
 Undo() – voids either AuthorizeAndCapture() or ReturnUnlinked() transactions
 QueryAccount() – returns the EBT card balances for both SNAP and cash benefits
SNAP purchase, cash purchase, SNAP return and balance inquiry transactions always require both a PIN and key
serial number. These transactions may be keyed or swiped, but the PIN and key serial number are always
required, regardless of entry mode. ReturnById() is not supported due to this PIN/KSN requirement.
SNAP voucher purchase and voucher return transactions are similar to credit force post transactions. When a
processing system is down, EBT customers may request a voucher to use in place of their EBT card. Customer
service at the retailer will call the issuing bank for approval then issue the customer a numbered voucher,
writing the issuer’s approval code on that voucher. The customer then presents the voucher for their SNAP
purchase. These transactions will always be keyed, must include the voucher number and the approval code,
and will never include a PIN or key serial number.
Cash back may only be used with cash purchases. SNAP purchases do not support cash back.
EBT cards do not currently include chips; therefore EMV processing is not included.
It is up to the card issuer to manage cardholder balances. Balances may or may not be returned on purchase
and return transactions, based on issuer behavior.
Required Fields for EBT Processing

 BankcardTransaction/TenderData/TenderType is required for all EBT transactions and must be set to
“ProcessAsEBT”. Not setting this flag will cause AuthorizeAndCapture() transactions to process as PIN
Debit and all other transactions to fail.
 BankcardTransaction/TenderData/CardData/CardType must be set to "EBT".
 BankcardTransaction/TenderData/CardSecurityData/KeySerialNumber must be present for all but
SNAP Voucher or Undo() transactions.

 BankcardTransaction/TenderData/CardSecurityData/PIN must be present for all but SNAP Voucher or
Undo() transactions.
 BankcardTransaction/TenderData/CardData/Track2Data must be present for all swiped transactions.
 BankcardTransaction/TenderData/CardData/PAN must be present for all keyed transactions.
 BankcardTransaction/TransactionData/EBTType must be present for all transactions and must be set to
either "SNAP" or "Cash". QueryAccount() can be set to either value, all card balances will be returned
regardless of this field setting.
The following fields are required for SNAP Voucher transactions only:
 BankcardTransaction/TenderData/VoucherApprovalCode is required must contain the approval code
received by the card issuer.
 BankcardTransaction/TenderData/VoucherNumber is required and must contain the number from the
voucher approved by the card issuer.
Recurring Bill Payment Processing

A recurring transaction is a transaction for which a cardholder provides written permission to a merchant to
periodically charge his/her account number for recurring goods or services. These may include payment of
charges such as insurance premiums, subscriptions, membership fees, tuition or utility charges. The recurring
transaction indicator must be present in the authorization. Address verification must be obtained with the initial
authorization request and is not required in the subsequent recurring transactions that contain the recurring
indicator. Address verification is required to be obtained yearly.
Recurring Bill Payments are supported in the MOTO and Ecommerce industry types.
BankcardTransactionPro/InterchangeData/BillPayment must be set to “Recurring”.
BankcardTransaction/TransactionData/CustomerPresent must be set to “BillPayment”.
BankcardTransactionPro/InterchangeData/ExistingDebt must be set to “NotExistingDebt”.
BankcardTransactionPro/InterchangeData/CurrentInstallmentNumber must be set to “1” for the first
transaction of a recurring payment series. Subsequent payments must be set to any value greater than 1.
BankcardTransaction/TransactionData/OrderNumber cannot be blank or all zeroes.
Installment Payment Processing

Installment Bill Payment is a transaction for which a cardholder provides permission for the merchant to charge
his/her account for a specified amount over a certain period of time. Example: If you were to purchase goods or
services for a total of $75.00 and you make 3 easy payments of $25.00. Installment transactions are card not
present transactions but Address Verification is only required to be obtained yearly.
Installment Bill Payments are supported in the MOTO and Ecommerce industry types.
BankcardTransactionPro/InterchangeData/BillPayment must be set to “Installment”.
BankcardTransactionPro/InterchangeData/ExistingDebt must be set to “NotExistingDebt”.

BankcardTransactionPro/InterchangeData/CurrentInstallmentNumber must be set to the correct installment
payment number for the current payment.
BankcardTransactionPro/InterchangeData/TotalNumberOfInstallments must be set to the correct total
number of installment payments.
Visa Debt Repayment Program

Merchants must be registered with Visa in order to participate in this program. Under this program, debt
repayment transactions involving qualified Visa merchants receive the debt repayment interchange fees by
meeting certain business requirements.
The debt repayment interchange fee applies to purchases and their related exception items. Credit voucher
transactions are not eligible for this program. Application-based e-commerce transactions from mobile devices
are eligible for this program.
Transactions from qualified merchants must have the following characteristics:
 Card type is consumer debit or prepaid
 Transaction must be Card Not Present
 Consumer credit cards and commercial card transactions are not eligible for this program
 Include a valid, Visa-assigned MVV
 MVV must match the MVV and acquirer BIN relationship registered with Visa
 MCC must be 6012 or 6051
 Transaction must be U.S. domestic
 Transactions must be CPS-qualified
 Transactions must be identified as Bill Payment transactions
 Transactions must be identified as Existing Debt
Visa Debt Repayment transactions are supported in the MOTO and Ecommerce industry. Only
AuthorizeAndCapture() may be used for these payments. Transactions that do not meet the criteria below
will be processed as normal authorization transactions, not debt repayment transactions.
Transaction Type must be AuthorizeAndCapture().
BankcardTransaction/TenderData/CardData/CardType must be “Visa”.
BankcardTransactionPro/InterchangeData/BillPayment must be set to “SinglePayment”.
BankcardTransactionPro/InterchangeData/ExistingDebt must be set to “IsExistingDebt”.
BankcardMerchantData/SIC must be set to either “6012” or “6051”.
Digital Wallet Processing

A digital wallet refers to an electronic device that allows a cardholder to make ecommerce transactions using
services like Apple Pay or Android Pay. In order to process digital wallet transactions, set the
BankcardTenderDataPro/TenderData/EcommerceSecurityData/TokenIndicator field to the corresponding
digital wallet system used: MasterPass, ApplePay, AndroidPay or SamsungPay. Enter the token from the digital
wallet service in the BankcardTenderDataPro/TenderData/EcommerceSecurityData/TokenData field.

Partial Reversal Processing
Partial reversal transactions are used to assist issuing banks with managing a cardholder’s open-to-buy balance,
allowing optimal use of their funds. This processing is especially important for prepaid cards and debit
cardholders where the balance represents a checking or savings account balance. Partial reversal transactions
should be submitted when:
 The final settlement amount was less than the authorized amount.
 The cardholder cancels or chooses not to complete all or part of the transaction.
 All or a portion of the goods or services could not be provided (for example, out-of-stock items).
In the U.S., merchants must submit a partial reversal within 24 hours of the original authorization request in a
card-present environment, and within 72 hours in a card-not-present environment.
It is up to the card issuer to support partial reversals and to manage cardholder balances. American Express
does not support partial reversal at this time.
In order to process a partial reversal, submit a Resubmit() transaction with ResubmitReason = Correction against
the approved Authorize() or AuthorizeAndCapture() transaction. The Amount of the Resubmit() must be the
final authorization amount. This Resubmit() cannot be voided (undone). To correct a Resubmit(), simply submit
another Resubmit() with the final authorization amount to override any previously submitted partial reversal(s).
All partial reversals must be submitted before the Authorize() is captured and before the batch is closed.
Partial reversals are excluded from the NGTrans duplicate checking logic.
3-D Secure Processing

Verified By Visa (VbV/VPAS)
If a token is obtained:
BankcardTransaction/TenderData/EcommerceSecurityData/TokenData is required and contains the
token provided by the service.
BankcardTransaction/TenderData/EcommerceSecurityData/TokenIndicator is required and must be
set to “VPAS”.
BankcardTransaction/TenderData/EcommerceSecurityData/XID is optional and may contain the Visa
XID value.
If VbV is supported but the token could not be obtained:
BankcardTransaction/TenderData/EcommerceSecurityData/TokenData will not be populated.
set to “AttemptedCardUnsupported” or “AttemptedServiceUnavailable”.
**NOTE – EVO NGTrans requires token data to be present in order to realize the benefit of 3-D Secure
processing.
MasterCard Secure Code (MCSC/UCAF)

NOTE: As of 13 November 2016, all MasterCard SecureCode transactions must include an Accountholder
Authentication Value (AAV) value (TokenData). Transactions without the AAV will be automatically downgraded
to a regular eCommerce transaction and will not benefit from the liability shift and other advantages of an
attempted SecureCode transaction.

If a token is obtained:
BankcardTransaction/TenderData/EcommerceSecurityData/TokenData is required and contains the
token provided by the service.
set to “UCAFWithData”.
If MCSC is supported but the token could not be obtained or will not be sent with the transaction:
BankcardTransaction/TenderData/EcommerceSecurityData/TokenData will not be populated.
set to “AttemptedCardUnsupported”, “AttemptedServiceUnavailable”, or “UCAFWithoutData”.
**NOTE – EVO NGTrans requires token data to be present in order to realize the benefit of 3-D Secure
processing.
Multiple Partial Capture Processing

Multiple Partial Capture processing refers to the process of submitting multiple partial Capture() transactions
against a single approved Authorize() transaction for split shipment transactions. The Authorize() transaction
must be for the anticipated total amount of the transaction. Capture() transactions can then be submitted
incrementally as items are shipped.
There can be any number of Capture() transactions as long as their total amount does not exceed the original
Authorize() amount. If an incremental Capture() exceeds the original Authorize() amount, NGTrans will decline
the Capture() with the StatusMessage “EXCEEDS MAX AMT”. This total amount validation is only performed
when at least one incremental Capture() is present.
In order to use Multiple Partial Capture processing, the Authorize() transaction must have the
BankcardTransaction/TransactionData/IsPartialShipment field set to “true”. This notifies NGTrans that
multiple partial captures will be submitted against this authorization.
Each Capture() transaction must have the BankcardTransaction/TransactionData/MultiplePartialCapture field
set to “true” and the BankcardTransaction/TransactionData/MultiplePartialCaptureFinal set to “false” for each
incremental Capture() or to “true” if the transaction is the final Capture() to be submitted.
The original Authorize() amount remains open until a Capture() with
BankcardTransaction/TransactionData/MultiplePartialCaptureFinal set to “true” is submitted. If the total
captured amount is less than the original authorized amount, NGTrans will submit a partial reversal on behalf of
the merchant in order to release the remaining funds from the cardholder’s open-to-buy balance.
Normal Capture() transactions may still be for an amount less than, equal to, or greater than the original
Authorize() transaction. These Capture() transactions will not include the multiple partial capture indicators.
Card brand tolerances apply to these Capture() transactions if they are greater than the original authorization.
Verify() Processing
Each card issuer decides which fields are required for verification. If possible, include both the PostalCode and
Street for the best verification results. Verify() may also include CVV/CID data.
American Express requires both postal code and address for Verify() transactions. If either field is missing, the
transaction will be declined.

BankcardTransaction/TenderData/CardSecurityData/AVSData/PostalCode
BankcardTransaction/TenderData/CardSecurityData/AVSData/Street
BankcardTransaction/TenderData/CardSecurityData/CVData
CVV/CID Processing
Merchant must sign up for American Express CVV program before values will be verified.
CVV is required on all Discover keyed transactions. Transactions that do not provide this value may be
surcharged depending on the Discover Merchant Agreement.
Partial Approvals (Partial

Authorization)
A partial authorization transaction enables a merchant to receive approval for a credit card's balance if that
balance is less than the transaction request amount. A split tender transaction results when a partial
authorization of the total purchase amount is returned to the device in the transaction response. The device
must then prompt for payment of the remaining balance due on the sale. The cardholder uses a different form
of payment, such as another payment card, cash, or a check. If the customer is not capable of completing the
transaction, the partial approval must be reversed (Undo()). If the reversal is declined, a return can be used to
remove the transaction from the cardholder’s account.
EVO NGTrans supports partial approval for Visa, MasterCard and Discover credit transactions. The
BankcardTransactionData/PartialApprovalCapable flag must be set to “Capable” on every transaction for which
a partial approval will be accepted. Not setting this flag will result in full approvals only, which may result in
more declines, especially for prepaid cards.
The StatusCode returned for a partially approved transaction is the same as the one returned for a fully
approved transaction. The response field BankcardTransactionResponse/IsPartialApproval will be set to “true”
if the transaction was partially approved.
Purchase Card - Level 2

EVO NGTrans supports Level 2 processing using the fields listed below. All fields should be submitted, except as
noted, in order to achieve the best interchange rates.
BankcardTransactionPro/TransactionData/Level2Data/CustomerCode – a customer code or purchase order
number supplied by the customer for this invoice.
BankcardTransactionPro/TransactionData/Level2Data/TaxExempt/TaxExemptNumber – the tax exempt ID
that should be applied to this invoice. Only used if the IsTaxExempt indicator is set to “Exempt”.
BankcardTransactionPro/TransactionData/Level2Data/CompanyName – the company name on the card.
BankcardTransactionPro/TransactionData/Level2Data/OrderNumber – an order or reference number supplied
by the merchant for this invoice.

BankcardTransactionPro/TransactionData/Level2Data/TaxExempt/IsTaxExempt – the tax exempt indicator for
this invoice.
 If the customer is tax exempt, set the indicator to “Exempt”.
 If the customer is not tax exempt and the tax amount is not included in the transaction, set the indicator
to “NotExemptTaxInfoNotProvided”.
 If the customer is not tax exempt and the tax amount is included in the transaction, set the indicator to
“NotExemptTaxInfoProvided”.
BankcardTransactionPro/TransactionData/Level2Data/FreightAmount – the amount of freight applied to this
invoice. This field is optional, but should be provided if available.
BankcardTransactionPro/TransactionData/Level2Data/Tax/Amount – the amount of tax applied to this invoice.
Unless the customer is tax exempt, this amount should always be provided. For tax exempt customers, submit
“0.00”.
Purchase Card – Level 3 (Line Item

Detail)
Merchants who process Level 3 (line item detail) transactions save money with lower interchange rates by
providing more detailed information about the transaction. Adding Level 3 processing allows merchants to tap
into the large ticket purchases of corporations and government agencies by attracting customers who use Level
3 purchase cards.
 EVO NGTrans will currently accept up to 99 line items for Level 3 processing. Merchants may submit
more than 99 line items, but no more than 99 will be processed.
 EVO NGTrans accepts Level 3 Data for Visa, MasterCard and American Express cards.
 Level 2 Data is required in order to qualify for Level 3 processing.
 At least one line item is required in order to qualify for Level 3 interchange rates.
In addition to the Level 2 Data listed above, the following fields should be submitted in order to qualify for the
lowest interchange rate. If any required fields are missing, transaction processing will continue but the data
will not be submitted to NGTrans and Level 3 processing will be forfeited.
 BankcardTransactionPro/TransactionData/Level2Data/DestinationCountryCode – optional
 BankcardTransactionPro/TransactionData/Level2Data/DestinationPostal – optional
 BankcardTransactionPro/TransactionData/Level2Data/DiscountAmount – optional
 BankcardTransactionPro/TransactionData/Level2Data/DutyAmount – optional
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/CommodityCode –
optional
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/Description – required
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/ProductCode – required

 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/Quantity – required
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/Amount – required
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/UnitOfMeasure – required
 BankcardTransactionPro/TransactionData/LineItemDetails/LineItemDetail/UnitPrice – required
Order Update Processing

Order update is used to add non-financial data to an approved AuthorizeAndCapture() transaction before the
batch is closed. For NGTrans, order update may be used to add Level 2 and Level 3 data and/or a product
identifier for B2B enrichment purposes.
In order to process an order update, submit a ResubmitOrderUpdate() transaction with ResubmitReason =
OrderUpdate against the approved AuthorizeAndCapture() transaction, adding the Level 2, Level 3 and/or
ProductIndicator information.
If the batch containing the approved AuthorizeAndCapture() transaction has closed before the order update is
submitted, the request will be declined with StatusCode “59” and StatusMessage “REC NOT FOUND”.
Order update transactions are excluded from the NGTrans duplicate checking logic.
This ResubmitOrderUpdate() cannot be voided (undone). To correct a ResubmitOrderUpdate(), submit another
ResubmitOrderUpdate() with corrected data to override any previously submitted order updates. To remove
previously submitted order update data, submit a new ResubmitOrderUpdate() without any additional data.
Adding non-financial information to an Authorize() transaction must be done in the Capture() transaction.
ReportingData/Reference Truncation
EVO NGTrans will accept up to 17 upper or lower case letters, numbers or spaces in this field. No special
characters are allowed. In order to allow merchants to send any data they choose in this field, EVO Snap* will
remove any special characters that exist and report the last 17 characters of the string if it is longer. For
example: PO-12345678901234567890 will send 45678901234567890 to NGTrans; ABC_123/R1C will send
ABC123R1C to NGTrans. The value sent to NGTrans will be returned to the merchant in the
BankcardTransactionResponse/Reference field.
Prepaid Card Final Balance

EVO NGTrans will return BankcardTransactionResponse/FinalBalance in an Authorize() or
AuthorizeAndCapture() response for prepaid cards if the card issuer returns the value. QueryAccount will always
return BankcardTransactionResponse/FinalBalance unless it results in an error. Any card may be used with
QueryAccount.
For Sandbox testing, customers can set BankcardTransaction/TenderData/CardData/PAN to 4005765777003
(Visa) or 5480020605154711 (MasterCard) in an Authorize() or AuthorizeAndCapture() request and the Sandbox
will return the value 10.00.

PAN Tokenization
Ecommerce merchants may now enroll for Visa and MasterCard tokenization, allowing them to accept the
assigned tokens associated with the requestor ID PAN numbers. The tokenized value is sent in place of the PAN
in the BankcardTransaction/TenderData/CardData/PAN field. EVO NGTrans will route these transactions to
Visa or MasterCard based on the BIN and they will process them accordingly. NGTrans will return the last four
(4) digits of the original PAN in the BankcardTransactionResponse/LastPANDigits field, which must then be
printed on the receipt.
Example:
Original PAN: 4003000123451000
Matching Token: 4895400000004459
Sale Request: BankcardTransaction/TenderData/CardData/PAN=4895400000004459
Sale Response: BankcardTransactionResponse/LastPANDigits =1000

End of Day
Batches may be manually closed using CaptureAll() or may be auto-closed by NGTrans.
Auto-close will be performed at either 3am Eastern or 6pm Eastern, depending on merchant setup.
Merchants may be configured for manual batch close only. These merchants will be excluded from the auto-
close process and must submit CaptureAll() in order for batches to be closed and settled.
Merchants that are not configured for manual batch close only may submit CaptureAll() but this will result in
multiple batch closings in a day, as auto-close will still be completed at the designated time.
EMV Processing
NGTrans supports EMV transactions for both Credit and PIN Debit processing. All EMV Data must be translated
from binary and submitted in HEX format.
Track 2 Data is required with EMV Data.
ApplicationData/ReadCapability must be set to “MSRKeyICC”, “MSREMVICC”, “Chip”, “EMVICC”, or
“ContactlessChip”.
BankcardTransactionDataDefaults/EntryMode must be set to “ChipReliable”, “ContactlessMChipOrSmartCard”,
“ChipTrack2DataFromRFID” or “ChipUnreliable”.
BankcardTransaction/TransactionData/CardholderAuthenticationEntity may be set to “ICC”.
ApplicationData/EMVTerminalData/CardDataOutputCapability may be set to “ICC”.
Offline EMV transactions must be uploaded the next time the terminal goes online. Authorizations must include
the terminal assigned approval code in BankcardTransaction/TransactionData/ApprovalCode. These
transactions are considered “force post” transactions and must be submitted for settlement. All other relevant
transaction data must also be present.
EMV PIN processing is now supported for QueryAccount(), Verify(), Authorize() and AuthorizeAndCapture().
BankcardTenderDataPro/TenderData/CardSecurityData/PIN,
BankcardTenderDataPro/TenderData/CardSecurityData/KeySerialNumber and
BankcardTenderDataPro/TenderData/CardholderIdType = “PIN” must be included for all Chip and PIN
transactions. All EMV transactions that include a PIN must include the
BankcardTransaction/TenderData/TenderType field in order to process correctly without errors.
 Credit = “ProcessAsCredit”
 PIN Debit = “ProcessAsPinDebit”
An Undo transaction must be sent if the chip declines a transaction that was approved by the host.
BankcardTransaction/TransactionData/UndoReason should be set to “SuspectMalfunction” for these reversals.
EMV Receipt Requirements

All General Receipt Requirements must be followed. In addition, EMV processed transaction receipts must
follow these guidelines:
• All EMV transaction receipts must display the Application Identifier (AID) number of the chip card
plan being processed (BankcardTransactionPro/TenderData/EMVData/ApplicationId). The AID shall
be printed as hexadecimal characters.

• All EMV transaction receipts must display the Terminal Verification Results (TVR) hexadecimal value
on the transaction receipt (BankcardTransactionPro/TenderData/EMVData/TerminalVerifyResult).
This value can help in troubleshooting errors caused by the financial application for an EMV
transaction processed. However, TVR and TSI are optional on refund receipts and are not applicable
on void receipts.
• If the transaction is performed with offline PIN for Cardholder Verification Method (CVM), then no
signature line is printed on the receipt but the following information is printed:
“By entering a verified PIN, cardholder agrees to pay issuer such total in accordance with
issuer’s agreement with cardholder”.
• When the applicable CVM is signature the terminal shall print a receipt with a line for cardholder
signature.
• It is a mandatory requirement that the receipt does not indicate whether a transaction was
processed online or offline.
• If the authorization is declined, the application should print a transaction receipt with the reason for
decline clearly stated.
• If a mobile devices battery is too low to print a receipt, the application should display a message
about the receipt printing issue, informing the user about recharging the battery in order to print
the transaction receipt.
• All receipts should include the Total Authorization Amount and the Tip Amount and/or Cash Back
Amount if included in the transaction.
Offline Funds Approval Receipt

Required fields:
1. Entry Method (Chip)
2. Approved message with authorization code
3. Disclaimer message to indicate transaction was verified by PIN
4. Preferred mnemonic associated with AID
5. Application Identifier (AID) used to process the transaction
6. Terminal Verification Results of transaction processed (TVR)
7. Transaction Status Information performed on the terminal (TSI)

Fallback Approval Receipt
Required fields:
1. Entry Method (Chip/Mag)

Offline Funds Decline Receipt
Required fields:
2. Declined message for offline funds

Signature CVM - Offline Funds Approval Receipt
Required fields:

Signature CVM – Online Approval Receipt

Required fields:


Could not Authorize Online – Offline Funds Approval Receipt
Required fields:

Could not Authorize Online – Offline Funds Declined Receipt
Required fields:
2. Declined message

Authorized Online Approval Using PIN Receipt
Required fields:


Authorized Online Declined Receipt
Required fields:
2. Declined message

Fallback Declined Receipt
Required fields:
2. Declined message

Fallback Declined Receipt
Required fields:


Fallback Refund Receipt
Required fields:

Offline Void Sale Receipt
Required fields:
1. Entry Method (retains original transaction information)
2. Offline Approved

Online Void Sale Receipt
Required fields:
2. Online Approved

Fallback Void Sale Receipt
Required fields:

Retail/Restaurant Tip Amount Offline Funds Approved Receipt
Required fields:
2. Approved message for offline funds with authorization code

Retail/Restaurant Tip Amount Online Funds Approved Using PIN
Receipt
Required fields:
2. Approved message for online funds with authorization code

Retail/Restaurant Tip Amount Offline Funds Approved Using Chip
and Signature Receipt
Required fields:
2. Approval message for offline funds with authorization code

Retail/Restaurant Tip Amount Online Funds Approved Using Chip
and Signature Receipt
Required fields:
2. Approval message for online funds with authorization code

Retail/Restaurant Tip Amount Fallback Approved Receipt
Required fields:

Response Codes
Transaction API Interface Elements v1.09
Reference Number: PSD-00094-1.0-20170719
Revised July 2017
Response Codes Sandbox Trigger Values - Transactions

To simulate Visa/MC tokenization with
return of last 4 digits of actual PAN, send txn
with PAN = 4895400000000242. Sandbox
will return LastPANDigits = 0653.
To simulate a host approved/chip declined

transaction, send EMV data in the request
with *.06 trigger value.
NGT
Status To simulate AUTH approved, VOID
Status Message Description Approve
Code declined send PAN 4111111111111112
d
(track 2 -
4111111111111112=2512502543219871234
5) to get response code 107 - CANNOT
VOID for VOID only
To simulate a Partial Approval response,

use cent trigger *.59. The approved response
amount will be $1.59, so the request value
should be at least $2.59.
0 UNKNOWN UNKNOWN NO N/A
APPROVED OR COMPLETED Any cent value not listed here will return this
1 AP YES
SUCCESSFULLY response for CREDIT transactions
REFER TO ISSUER
2 CALL (AMERICAN EXPRESS, NO *.03
DINERS, ETC.)
TOUCHTONE CAPTURE,
3 CALL WON'T ROLL TO AN NO N/A
OPERATOR
4 INVLD MERCH ID INVALID MERCHANT ID NO *.04
5 PIC UP AUTHORIZATION DECLINED NO *.05
6 DECLINE AUTHORIZATION DECLINED NO *.07
REQUESTED TRANSACTION
7 REVERSED REVERSAL WAS YES N/A
SUCCESSFUL
RESPONSE FOR CVV2
8 DECLINE-CV2 FAIL NO *.08
FAILURE. DECLINED. (VISA)
APPROVED WITH POSITIVE
ID. HOST DOES NOT
9 APP WITH ID YES *.02
CAPTURE THIS
TRANSACTION.
ADMINISTRATIVE MESSAGE
10 INVLD REQUEST NO N/A
CONTAINS A SYNTAX ERROR
AMOUNT ENTERED IN
11 INVLD AMOUNT NO *.09
INVALID.
ACCOUNT NUMBER DOES
12 INVLD ACCT NOT PASS ISSUER'S EDIT NO *.10
CHECKS
GATEWAY REQUESTS A
13 PLEASE RETRY NO *.11
RETRY
EXPIRATION DATE ENTERED
14 INVLD EXP DATE NO *.12
IS INCORRECT

with PAN = 4895400000000242. Sandbox

NGT
d
(track 2 -
4111111111111112=2512502543219871234
VOID for VOID only

15 PIN INVALID INCORRECT PIN ENTERED NO *.13
MERCHANT NOT SET UP FOR
16 SERV NOT ALLOWED NO *.14
TRANSACTION CODE USED
MAXIMUM PIN NUMBER
17 MAX PIN RETRIES ENTRY ATTEMPTS NO *.15
EXCEEDED
TRANSACTION ENTERED IS A
18 AP DUPE NO *.01
DUPLICATE
19 NETWORK UNAVAIL SYSTEM UNAVAILABLE NO *.16
THE ACCOUNT NUMBER

ENTERED DURING A VOID OR
ADJUSTMENT TRANSACTION
20 INV ACCT MATCH NO N/A
DOES NOT MATCH THE
ACCOUNT NUMBER STORED
IN THE HOST FOR THAT ITEM.
THE AMOUNT ENTERED FOR
A VOID OR ADJUSTMENT
TRANSACTION DOES NOT
21 INV AMT MATCH NO N/A
MATCH THE AMOUNT
STORED IN THE HOST FOR
THAT ITEM.
THE ITEM NUMBER ENTERED
FOR A VOID OR ADJUSTMENT
22 INV ITEM NUM NO N/A
TRANSACTION IS
INCORRECT
AN ADJUSTMENT OR ITEM
REVIEW WAS ATTEMPTED
23 ITEM VOIDED ON A TRANSACTION NO N/A
PREVIOUSLY VOIDED OR
REVERSED.
TERMINAL HAS NOT BEEN
BALANCED WITHIN TIME
SPECIFIED IN THE GLOBAL
24 MUST BALANCE NOW NO N/A
PAYMENTS MERCHANT
MASTER FILE FOR THIS
MERCHANT.
TERMINAL HAS NOT BEEN
BALANCED WITHIN TIME
SPECIFIED IN THE GLOBAL
USE DUP THEN PAYMENTS MERCHANT
25 BALBEFORE MASTER FILE FOR THIS NO N/A
BALANCING. MERCHANT, BUT MERCHANT
IS SET UP TO PERFORM
EXTRA TRANSACTIONS
BEFORE BALANCING.

with PAN = 4895400000000242. Sandbox

NGT
d
(track 2 -
4111111111111112=2512502543219871234
VOID for VOID only

OVERRIDE TRANSACTION IS
26 NO DUP FOUND ATTEMPTED ON A NON- NO *.17
DUPLICATED TRANSACTION.
FORMAT OF THE
27 INVALID DATA TRANSACTION IS NO *.18
INCORRECT.
REVERSAL TRANSACTION IS
ATTEMPTED ON A
28 NO TRANS FOUND TRANSACTION THAT IS NOT NO N/A
IN THE OPEN BATCH ON THE
HOST.
APPROVED BUT NOT
29 AP NOT CAPTURED CAPTURED (APPLIES ONLY YES N/A
TO CREDIT TRANSACTIONS)
APPROVED BUT THIS EDC
MERCHANT IS NOT SET UP
30 AP AUTH-ONLY TO CAPTURE THIS CARD YES N/A
TYPE (APPLIES ONLY TO
CREDIT TRANSACTIONS)
ACQUIRING BANK ID
31 INV BANK NO N/A
ENTERED IS INCORRECT
TRANSACTION NOT
32 TRAN TYPE INVLD SUPPORTED BY EFT NO N/A
NETWORK OR CARD ISSUER
APPROVED DEBIT Any cent value not listed here will return this
33 APPROVED YES
TRANSACTION response for PINDEBIT transactions
34 DB UNAVAIL 02 GATEWAY IS DOWN NO *.19
35 DB UNAVAIL 03 GATEWAY LINK TIMED OUT NO N/A
GATEWAY CANNOT
36 DB UNAVAIL 04 CONTACT EFT NETWORK OR NO N/A
EFT GROUP ID IS INCORRECT
MERCHANT IS NOT SETUP
37 UNAUTH USER FOR DEBIT ON MERCHANT NO *.20
MASTER FILE.
38 INVALID CARD DEBIT NOT ON ISSUER FILE. NO *.21
EFT NETWORK CANNOT
39 ISSUER UNAVAIL NO N/A
CONTACT ISSUER
CARD IS NOT ELIGIBLE FOR
40 INVALID POS CARD NO *.22
POS
TYPE OF ACCOUNT ENTERED
41 ACCT TYPE INVLD CANNOT BE ACCESSED NO *.23
(CHECKING, SAVINGS, ETC.)

with PAN = 4895400000000242. Sandbox

NGT
d
(track 2 -
4111111111111112=2512502543219871234
VOID for VOID only

NO SHARING ARRANGEMENT
42 INVALID PREFIX NO N/A
FOR THIS CARD
GATEWAY FINANCIAL
43 INVALID FIID NO *.24
INSTITUTION ID NOT SET UP
MATCH ON SCAN FILE.
XXXXXXXXX IS
44 VERIFY XXXXXXXXX NO N/A
ROUTING/TRANSIT NUMBER
ON THE NEGATIVE FILE.
THE LICENSE OR ID NUMBER
ENTERED DURING A CHECK
45 INVALID LIC AUTHORIZATION NO N/A
TRANSACTION IS
INCORRECT
EDC APPLICATION DOWN,
46 EDC UNAVAILABLE NO N/A
TRY LATER.
DEBIT APPLICATION DOWN,
47 DB UNAVAIL 01 NO *.25
TRY LATER.
SCAN APPLICATION IS
48 SCAN UNAVAILABLE NO N/A
DOWN, TRY LATER
EXCEEDS WITHDRAWAL
49 EXCEEDS MAX AMT NO *.26
AMOUNT LIMIT
EXCEEDS WITHDRAWAL
50 EXCEEDS MAX USES NO *.27
FREQUENCY LIMIT
SUCCESSFUL SETTLEMENT -
51 OK YES N/A
FINAL BLOCK
ACQUIRER REFERENCE
DATA DID NOT PASS FIELD
52 INV ACQ REF DATA DEFINITION EDITS AS NO *.28
SPECIFIED IN THE FIELD
DESCRIPTIONS.
MERCHANT IS MARKED AS
53 INVALID BATCH NO N/A
INACTIVE ON EDC.
54 INV BATCH NBR INVALID BATCH NUMBER. NO *.29
TOTALS IN POS DEVICE DO
NOT MATCH HOST TOTALS
AND THERE ARE NO
INV REVERSALS, OR POS
55 BAL/SETLDIFFERENC TOTALS DO NOT AGREE NO N/A
E. WITH HOST TOTALS AND THE
REVERSALS CANNOT
ACCOUNT FOR THE
DIFFERENCE.

with PAN = 4895400000000242. Sandbox

NGT
d
(track 2 -
4111111111111112=2512502543219871234
VOID for VOID only

SETTLEMENT IS
SUCCESSFUL, BUT THE
56 OK DB XXXX/XXXX AMOUNT AND ITEM COUNT NO N/A
DO NOT MATCH THE TOTALS
IN THE HOST.
INVALID REFERENCE
57 INV REF NO NO *.30
NUMBER
58 VOID ERROR VOID ERROR NO N/A
59 REC NOT FOUND RECORD NOT FOUND NO *.31
60 INV APP CODE INVALID APPROVAL CODE NO *.32
101 CARD NOT FOUND CARD NOT FOUND NO *.33
102 CARD NOT ACTIVE CARD NOT ACTIVE NO *.35
103 CARD EXPIRED CARD EXPIRED NO *.36

CARD CAN NOT BE
104 CAN NOT ACCEPT ACCEPTED BY THIS NO *.37
MERCHANT
CARD IS ALREADY
105 ALREADY ACTIVE NO N/A
ACTIVATED
106 NEGATIVE BAL CARD NEGATIVE BALANCE NO N/A
PAN 4111111111111112 (track 2 -
4111111111111112=2512502543219871234
107 CANNOT VOID CANNOT VOID TRANSACTION NO
5) to get an approved authorization followed
by a declined void
CARD TRANSACTION IS
108 ALREADY VOIDED NO N/A
ALREADY VOIDED
INVALID AUTH NUMBER FOR
109 INVALID AUTH NO NO N/A
VOID TRANSACTION
NO AUTH NUMBER FOR VOID
110 NO AUTH NUMBER NO N/A
TRANSACTION
INVALID DATA FOR VOID
111 INCORRECT DATA NO N/A
TRANSACTION
112 SYSTEM ERROR SYSTEM ERROR NO *.38
113 INVLD VOUCHER ID INVALID VOUCHER ID NO *.39
INVALID ESTABLISHMENT ID
114 INVALID EST ID NO *.40
(FCS OR SE)
115 LOST CARD LOST CARD NO *.41
116 INSUF FUNDS INSUFFICIENT FUNDS NO N/A

with PAN = 4895400000000242. Sandbox

NGT
d
(track 2 -
4111111111111112=2512502543219871234
VOID for VOID only

FRAUD RETURN
117 FRAUD RETURN CARD NO *.42
CARD
118 VOUCHER EXPIRED VOUCHER EXPIRED NO *.43
119 CARD DEACTIVATED DEACTIVATED CARD NO N/A
120 INVLD MER NAME INVALID MERCHANT NAME NO *.44
INVALID MERCHANT STREET

121 INVLD MER STREET NO *.45
ADDRESS
122 INVLD MER CITY INVALID MERCHANT CITY NO *.46
123 INVLD MER STATE INVALID MERCHANT STATE NO *.47
INVALID MERCHANT ZIP

124 INVLD MER ZIP NO *.48
CODE
INVALID MERCHANT
125 INVLD MCC NO N/A
CATEGORY CODE
FOR MANUAL APPROVAL.
MERCHANT MUST CALL
126 REFERRED NO *.49
CUSTOMER SERVICE FOR
APPROVAL
127 INVALID TERM ID INVALID TERMINAL ID NO *.50
128 INACTIV TERM ID INACTIVE TERMINAL ID NO *.51
129 INACTIV MER ID INACTIVE MERCHANT ID NO *.52

130 INACTIV DIV ID INACTIVE DIVISION ID NO *.53
131 INACTIV CLI ID INACTIVE CLIENT ID NO *.54
PIN PAD CONFIGURATION
132 PIN PAD CONFIG ERROR, SEE CRYPTOCONFIG NO *.55
SETUP
TRANSACTION ENTERED IS A
133 RESPONSE RESENT DUPLICATE. RESPONSE NO *.56
RESENT
134 BATCH IS CLOSED BATCH IS ALREADY CLOSED NO N/A
INVALID MERCHANT
135 INVLD MER CFG NO *.57
CONFIGURATION

Business Rules and Guidelines EVO NGTrans BCP

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Business Rules and Guidelines EVO NGTrans BCP

Încărcat de

Drepturi de autor:

Formate disponibile

Business Rules and

Offline Funds Approval Receipt......................................................................................................................16

Making Payments a Snap* for Developers | Proprietary & Confidential 1

Making Payments a Snap* for Developers | Proprietary & Confidential 2

Making Payments a Snap* for Developers | Proprietary & Confidential 3

Making Payments a Snap* for Developers | Proprietary & Confidential 4

Duplicate Transaction Detection and

Making Payments a Snap* for Developers | Proprietary & Confidential 5

PIN Debit Processing

Required Fields for EBT Processing

Making Payments a Snap* for Developers | Proprietary & Confidential 6

Recurring Bill Payment Processing

Installment Payment Processing

Making Payments a Snap* for Developers | Proprietary & Confidential 7

Visa Debt Repayment Program

Digital Wallet Processing

Making Payments a Snap* for Developers | Proprietary & Confidential 8

3-D Secure Processing

MasterCard Secure Code (MCSC/UCAF)

Making Payments a Snap* for Developers | Proprietary & Confidential 9

Multiple Partial Capture Processing

Making Payments a Snap* for Developers | Proprietary & Confidential 10

Partial Approvals (Partial

Purchase Card - Level 2

Making Payments a Snap* for Developers | Proprietary & Confidential 11

Purchase Card – Level 3 (Line Item

Making Payments a Snap* for Developers | Proprietary & Confidential 12

Order Update Processing

Prepaid Card Final Balance

Making Payments a Snap* for Developers | Proprietary & Confidential 13

Making Payments a Snap* for Developers | Proprietary & Confidential 14

EMV Receipt Requirements

Making Payments a Snap* for Developers | Proprietary & Confidential 15

Offline Funds Approval Receipt

Making Payments a Snap* for Developers | Proprietary & Confidential 16

Making Payments a Snap* for Developers | Proprietary & Confidential 17

Making Payments a Snap* for Developers | Proprietary & Confidential 19

Making Payments a Snap* for Developers | Proprietary & Confidential 20

Signature CVM – Online Approval Receipt

Making Payments a Snap* for Developers | Proprietary & Confidential 21

Making Payments a Snap* for Developers | Proprietary & Confidential 22

Making Payments a Snap* for Developers | Proprietary & Confidential 23

Making Payments a Snap* for Developers | Proprietary & Confidential 24

Making Payments a Snap* for Developers | Proprietary & Confidential 25

Making Payments a Snap* for Developers | Proprietary & Confidential 26

Making Payments a Snap* for Developers | Proprietary & Confidential 27

Making Payments a Snap* for Developers | Proprietary & Confidential 28

Making Payments a Snap* for Developers | Proprietary & Confidential 29

Making Payments a Snap* for Developers | Proprietary & Confidential 30

Making Payments a Snap* for Developers | Proprietary & Confidential 31

Making Payments a Snap* for Developers | Proprietary & Confidential 32

Making Payments a Snap* for Developers | Proprietary & Confidential 33

Making Payments a Snap* for Developers | Proprietary & Confidential 34

Making Payments a Snap* for Developers | Proprietary & Confidential 35

Making Payments a Snap* for Developers | Proprietary & Confidential 37

Making Payments a Snap* for Developers | Proprietary & Confidential 38

Making Payments a Snap* for Developers | Proprietary & Confidential 40

Making Payments a Snap* for Developers | Proprietary & Confidential 42

Response Codes Sandbox Trigger Values - Transactions

To simulate a host approved/chip declined

To simulate a Partial Approval response,

Making Payments a Snap* for Developers | Proprietary & Confidential 44

To simulate a host approved/chip declined

To simulate a Partial Approval response,