Technical - Magento 2€¦ · Technical Specification . Online Processing Format Specification . Version 7.4 – Revision 12.4 . November 12, 2017

Technical Specification Online Processing Format Specification Version 7.4 – Revision 12.4 November 12, 2017

© Paymentech, LLC. All rights reserved ii November 12, 2017

Disclosure Statement This document contains information which is confidential and proprietary to Paymentech, LLC, Merchant Services Solutions and Merchant Services Europe Limited (collectively “Chase”) and may only be used in relation to services and products provided by Merchant Services. Merchant Services is a marketing name for the Merchant Acquiring and Payment Processing business of JPMorgan Chase & Co. (“JPMorgan Chase”). This document contain information that is confidential and/or proprietary to Merchant Services and/or JPMorgan Chase and may not be copied, used or published, in whole or in part, for any purpose other than as expressly authorized by Merchant Services. Merchant Services makes no representations as to the legal, regulatory, tax or accounting implications or suitability for any particular business of the matters referred to in this document. All trademarks, trade names and service marks appearing herein are the property of their respective owners. © 2017 Paymentech, LLC. All Rights Reserved

© Paymentech, LLC. All rights reserved iii November 12, 2017

The following general changes have been incorporated in Online Processing Format Technical Specification Version 7.4 Revision 12.4

Page No(s) Action Description of Change Chip EMV Data Format Indicator

61 Updated Notes section to add an additional note about EMV Tag 97FC. APPENDIX A: RESPONSE REASON CODE DESCRIPTION AND USAGE

285 Updated Appendix to add a new Response Reason Code (285 - Customer Exclusive Data (CED Missing))

The following changes for Dynamic Token Verification Code (DTVC) have been incorporated in Online Processing Format Specification Version 7.4 Revision 12.4

Page No(s) Action Description of Change

Fraud Format Indicator (FR) 91 Updated The Card Security Presence field to include a new note for valid

value “1”. 93 Updated The Card Security Value field to include a new note about

Dynamic Token Verification Code (DTVC) APPENDIX AM: CONSUMER DIGITAL PAYMENT TOKEN

673-731 Updated Appendix to include information for DTVC in the How It Works section and to include DTVC information in the Transaction Types and Requirements section. Also added Batch transaction type examples for DTVV.

The following changes for Voltage Upgrade Project have been incorporated in

Online Processing Format Specification Version 7.4 Revision 12.4

Page No(s) Action Description of Change APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION

453 Updated Sample Tokens for Tokenization section with new values. 454 Updated Safetech Tokenization Format Examples with new values and a

new column in the table.

© Paymentech, LLC. All rights reserved iv November 12, 2017

The following changes for ACCESS FX Cross Currency have been incorporated in Online Batch Processing Format Specification Version 7.4 Revision 12.4

Page No(s) Action Description of Change Additional Request Processing Formats

28 Updated Table to add the new ACCESS FX Cross Currency Format Indicator (FX).

ACCESS FX Cross Currency Format Indicator (FX) 95-96 Added New format indicator

Return Response Processing Formats 204 Updated Table to add the new ACCESS FX Cross Currency Reply Format

Indicator (FX). ACCESS FX Cross Currency Reply Format Indicator

240-242 Added New Reply Format Indicator APPENDIX AR: ACCESS FX CROSS CURRENCY

800-807 Added New Appendix

© Paymentech, LLC. All rights reserved v November 12, 2017

TECHNICAL SPECIFICATION FOR ONLINE PROCESSING

Table of Contents RECORD LAYOUTS .................................................................................................................... 1 Introduction ................................................................................................................................ 1 Online Processing Detail Record ............................................................................................... 2

Table 1: Action Code Definitions ......................................................................................... 22 Additional Request Processing Formats ...................................................................................27

Customer ANI Format Indicator (AA) ................................................................................... 31 Bill to Address Format Indicator (AB)................................................................................... 32 Employer Information Format Indicator (AE) ........................................................................ 34 Giftee Information Format Indicator (AG) ............................................................................. 36 Customer Host Format Indicator (AH) ................................................................................. 38 IP Address Format Indicator (AI) ......................................................................................... 39 Email Address Format Indicator (AL) ................................................................................... 40 Customer Browser Format Indicator (AR) ............................................................................ 41 Ship to Address Format Indicator (AS) ................................................................................ 42 ECP Advanced Verification 1 Format Indicator (AV01) ........................................................ 44 ECP Advanced Verification 2 Format Indicator (AV02) ........................................................ 46 ECP Advanced Verification 3 Format Indicator (AV03) ........................................................ 48 ECP Advanced Verification 4 Format Indicator (AV04) ........................................................ 49 Postal Code Only Address Format Indicator (AZ) ................................................................ 51 Agreement Description Format Indicator (BD) ..................................................................... 52 Bill Me Later Format Indicator (BL) ...................................................................................... 53 Bill Me Later Information Format Indicator (BM) .................................................................. 55 Bill Me Later Private Label Format Indicator (BP) ................................................................ 58 Cash Back Format Indicator (CO) ....................................................................................... 60 Chip EMV® Data Format Indicator (CP) .............................................................................. 61 Card Type Indicator Format Indicator (CT) .......................................................................... 63 Debit Information Format Indicator – PIN-Based Debit Only (DB) ........................................ 64 Discover Authentication Format Indicator (DA) .................................................................... 66 Digital PAN Format Indicator (DN) ....................................................................................... 68 Direct Pay Format Indicator (DP) ......................................................................................... 70 Debit Routing Format Indicator (DR) ................................................................................... 76 Digital Wallet Format Indicator (DW) ................................................................................... 77 European Direct Debit 2 Format Indicator (E2) .................................................................... 80 Electronic Benefits Transfer Format Indicator (EBT) ............................................................ 84 Electronic Check Processing Format Indicator (EC) ............................................................ 85 European Direct Debit Format Indicator (ED) ...................................................................... 86 Safetech Page Encryption Format Indicator (EI) .................................................................. 88 Gift Card Format Indicator (FC) ........................................................................................... 90 Fraud Format Indicator (FR) ................................................................................................ 91 ACCESS FX Cross Currency Format Indicator (FX) ............................................................ 95 Goods Sold Format Indicator (GS) ...................................................................................... 97 Formatted Ship To Name Format Indicator (HN) ................................................................. 98 Healthcare IIAS Format Indicator (II) ................................................................................... 99 JCB Authentication Format Indicator (JA) .......................................................................... 101 Fraud Scoring 1 Format Indicator (KT01) .......................................................................... 105 Fraud Scoring 2 Format Indicator (KT02) .......................................................................... 107 User Defined and Shopping Cart Format Indicator (KTT1) ................................................ 110

© Paymentech, LLC. All rights reserved vi November 12, 2017

Lodging Format Indicator (LG)........................................................................................... 115 Formatted Bill to Name Format Indicator (LN) ................................................................... 116 MasterCard Authentication Format Indicator (MA) ............................................................. 117 Mobile POS Device Information Format Indicator (MB) ..................................................... 119 Merchant Descriptor Format Indicator (MD) ....................................................................... 120 Merchant Echo Format Indicator (ME) ............................................................................... 123 MoneyPak Format Indicator (MP) ...................................................................................... 124 Message Type Records Format Indicator (MT) ................................................................. 125 Miscellaneous 1 Format Indicator (M1) .............................................................................. 127 Order Information Format Indicator (OI) ............................................................................ 128 Order Information 2 Format Indicator – PINless Debit Only (O2) ....................................... 130 Order Information 3 Format Indicator (O3) ........................................................................ 131 Order Information 5 Format Indicator (O5) ........................................................................ 132 Order Information 6 Format Indicator (O6) ........................................................................ 133 Order Information 7 Format Indicator (O7) ........................................................................ 135 Prior Authorization and Reversal Reason Format Indicator (P4) ........................................ 136 Prior Authorization Format Indicator (PA) .......................................................................... 138 Partial Authorization Format Indicator (PB)........................................................................ 140 Payment Device Format Indicator (PD) ............................................................................. 142 Personal Information Format Indicator (PI) ........................................................................ 144 Payment Action Format Indicator (PM) .............................................................................. 146 Page Set Up Format Indicator (PS) ................................................................................... 148 Personal Information 2 Format Indicator (P2) .................................................................... 150 Recipient Data Format Indicator (RD) ................................................................................ 151 Retail Format Indicator (RE) .............................................................................................. 153 Request Information Format Indicator (RI)......................................................................... 156 Reversal Format Indicator – Gift Card Only (RV) ............................................................... 157 Retail 2 Format Indicator (R2) ........................................................................................... 158 Retail 3 Format Indicator (R3) ........................................................................................... 160 Soft Merchant Information Format Indicator (SM) .............................................................. 165 Split Tender Format Indicator (ST) .................................................................................... 168 Soft Merchant Information 2 Format Indicator (S2) ............................................................ 169 Soft Merchant Information 3 Format Indicator (S3) ............................................................ 173 Soft Merchant Information 4 Format Indicator (S4) ............................................................ 178 Token ID Format Indicator (TI) .......................................................................................... 183 URL and Address Flag Format Indicator (US) ................................................................... 184 Visa Authentication Format Indicator (VA) ......................................................................... 186 Various Text Format Indicator (VT) ................................................................................... 190 American Express Authentication Format Indicator (XA) ................................................... 191

Online Processing Return Format Record ............................................................................... 195 Return Response Processing Formats .................................................................................... 204

Bill To Address Reply Format Indicator (AB) ..................................................................... 206 Email Address Reply Format Indicator (AL) ....................................................................... 208 Ship To Address Reply Format Indicator (AS) ................................................................... 209 ECP Advanced Verification Reply Format Indicator (AV) ................................................... 211 Bill Me Later Reply Format Indicator (BM) ......................................................................... 220 Balance Inquiry Reply Format Indicator (BQ) .................................................................... 222 Bill Me Later Private Label (BML PL) Reply Format Indicator (BR) .................................... 223 Balance Inquiry 2 Reply Format Indicator (BX) .................................................................. 224 Cash Back Reply Format Indicator (CO) ........................................................................... 225 Card Issuing Country Status Reply Format Indicator (CS) ................................................. 226 Card Type Indicator Reply Format Indicator (CT01) .......................................................... 227 Card Type Indicator Reply Format Indicator (CT02) .......................................................... 230 Chip EMV® Reply Format Indicator (CP) .......................................................................... 233

© Paymentech, LLC. All rights reserved vii November 12, 2017

Debit Reply Format Indicator (DB) ..................................................................................... 234 Digital PAN Reply Format Indicator (DN) ........................................................................... 235 European Direct Debit 2 Reply Format Indicator (E2) ........................................................ 236 Electronic Benefits Transfer Reply Format Indicator (EBT) ................................................ 237 Gift Card Reply Format Indicator (FC) ............................................................................... 239 ACCESS FX Cross Currency Reply Format Indicator (FX) ................................................ 240 Gift Card Block Activation Reply Format Indicator (F1) ...................................................... 243 Rules Triggered Reply Format Indicator (KR) .................................................................... 244 Fraud Scoring 1 Reply Format Indicator (KT01) ................................................................ 245 Fraud Scoring 2 Reply Format Indicator (KT02) ................................................................ 247 Merchant Echo Reply Format Indicator (ME) ..................................................................... 255 MoneyPak Reply Format Indicator (MP) ............................................................................ 256 Message Type Records Reply Format Indicator (MT) ....................................................... 257 Partial Authorization Reply Format Indicator (PB).............................................................. 258 Personal Information 2 Reply Format Indicator (P2) .......................................................... 259 Response Information Reply Format Indicator (RI) ............................................................ 260 Response Message Reply Format Indicator (RM) ............................................................. 263 Shop with Points Information Reply Format Indicator (SI) .................................................. 264 Shop with Points Reply Format Indicator (SP) ................................................................... 265 Token ID Reply Format Indicator (TI) ................................................................................ 267 Transaction ID Reply Format Indicator (TX) ...................................................................... 268 Visa Transaction Identifier Reply Format Indicator (VI) ...................................................... 269

FORMAT USAGE ..................................................................................................................... 270 Sample Record Layouts .......................................................................................................... 270 APPENDIX A: RESPONSE REASON CODE DESCRIPTION/USAGE .................................... 279 Merchant Services Response Reason Codes ......................................................................... 279 Authorization/ Verification Codes ............................................................................................ 296 APPENDIX B: ADDRESS VERIFICATION ............................................................................... 297 Introduction ............................................................................................................................. 297 Types of Address Records ...................................................................................................... 297 JCB ......................................................................................................................................... 297 Address Verification Process .................................................................................................. 298 American Express and JCB Canadian Merchants Advanced Verification ................................ 299 Discover, Discover Diners, and JCB Address Verification Service .......................................... 301 Address Verification Exceptions .............................................................................................. 303 AVS Response Codes ............................................................................................................ 304 AVS Response Key ................................................................................................................ 305 Postal Code Format ................................................................................................................ 305 APPENDIX C: ERROR SCREENING ....................................................................................... 306 Bad Account Number Check ................................................................................................... 306 MOD 10 Check Digit ............................................................................................................... 306 Account Number Prefix Check ................................................................................................ 309 Account Number Length Check .............................................................................................. 310 APPENDIX D: INTERNATIONAL PROCESSING .................................................................... 311 Introduction ............................................................................................................................. 311 Contractual Agreement ........................................................................................................... 311 Transaction Division Numbers ................................................................................................ 311 Zero Decimal Currency Example ............................................................................................ 311 Multi-Currency Processing ...................................................................................................... 312 Cross-Currency Processing .................................................................................................... 313 Presentment Currencies ......................................................................................................... 313 APPENDIX E: CARD SECURITY VERIFICATION ................................................................... 319 Introduction ............................................................................................................................. 319 American Express CID Program ............................................................................................. 319

© Paymentech, LLC. All rights reserved viii November 12, 2017

Bill Me Later Private Label VAK Program ................................................................................ 320 Discover, Discover Diners, and JCB CID Program .................................................................. 320 International Maestro and MasterCard CVC2, MasterCard Canadian Domestic Restricted Debit CVV2 ChaseNet, Visa, Visa Canadian Domestic Restricted Debit CVV2 Program ................. 320 Gift Card CVD2 Program ........................................................................................................ 321 Guidelines for Populating Card Security Fields ....................................................................... 321 Card Types / Supported Currencies ........................................................................................ 322 Response Reason Codes ....................................................................................................... 322 To Get Started ........................................................................................................................ 322 APPENDIX F: AUTHORIZATION REVERSALS ...................................................................... 323 Introduction ............................................................................................................................. 323 How it works ........................................................................................................................... 323 Transaction Types and Requirements ..................................................................................... 325 Additional References ............................................................................................................. 326 Card Types / Supported Currencies ........................................................................................ 326 Response Reason Codes ....................................................................................................... 326 To Get Started ........................................................................................................................ 326 APPENDIX G: PARTIAL AUTHORIZATION ............................................................................ 327 Introduction ............................................................................................................................. 327 How It Works .......................................................................................................................... 327 American Express and JCB .................................................................................................... 328 Discover and Discover Diners ................................................................................................. 330 ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit ............................................................... 339 MoneyPak ............................................................................................................................... 341 PIN-Based Debit ..................................................................................................................... 342 Transaction Types and Requirements ..................................................................................... 345 Transaction Types and Requirements for PIN-Based Debit .................................................... 347 Card Types / Supported Currencies ........................................................................................ 348 Response Reason Codes ....................................................................................................... 348 To Get Started ........................................................................................................................ 348 APPENDIX H: VERIFIED BY VISA .......................................................................................... 349 Introduction ............................................................................................................................. 349 How It Works .......................................................................................................................... 349 Merchant Requirements .......................................................................................................... 352 Failed Authentications ............................................................................................................. 353 Split Shipments ....................................................................................................................... 353 Late Fulfillment........................................................................................................................ 354 Recurring Transactions ........................................................................................................... 354 Online Auctions ....................................................................................................................... 354 Chargeback Liability Shift Exclusions ...................................................................................... 355 Transaction Types and Requirements ..................................................................................... 356 Card Types / Supported Currencies ........................................................................................ 358 Response Reason Codes ....................................................................................................... 358 To Get Started ........................................................................................................................ 358 APPENDIX I: MASTERCARD SECURECODE ........................................................................ 359 Introduction ............................................................................................................................. 359 How It Works .......................................................................................................................... 359 Processing Requirements for Merchants Using International Maestro and the Maestro Advanced Registration Program or the MasterCard Advanced Registration Program (MARP) ................ 361 Maestro Recurring Payments Program (MRPP) ...................................................................... 363 Merchant Requirements .......................................................................................................... 364 Merchant Guidelines (Excludes MARP and MRPP) ................................................................ 365 Transaction Types and Requirements for MasterCard ............................................................ 366

© Paymentech, LLC. All rights reserved ix November 12, 2017

Transaction Types and Requirements for International Maestro ............................................. 369 Card Types / Supported Currencies ........................................................................................ 371 Response Reason Codes ....................................................................................................... 371 To Get Started ........................................................................................................................ 371 APPENDIX J: MASTERCARD AND VISA DIGITAL WALLET ................................................. 372 Introduction ............................................................................................................................. 372 How it works ........................................................................................................................... 372 Transaction Types and Requirements ..................................................................................... 374 Card Types / Supported Currencies ........................................................................................ 377 Response Reason Codes ....................................................................................................... 377 To Get Started ........................................................................................................................ 377 APPENDIX K: EUROPEAN DIRECT DEBIT ............................................................................ 378 Introduction ............................................................................................................................. 378 How It Works .......................................................................................................................... 378 Processing Requirements ....................................................................................................... 382 Transaction Types and Requirements for Non-IBAN ............................................................... 383 Transaction Types and Requirements for IBAN ...................................................................... 388 Card Types / Supported Currencies ........................................................................................ 392 Response Reason Codes ....................................................................................................... 392 To Get Started ........................................................................................................................ 392 APPENDIX L: DEBIT PROCESSING ....................................................................................... 393 Introduction ............................................................................................................................. 393 Authorizations and Deposits.................................................................................................... 393 Authorizations and Deposits: How It Works ............................................................................. 393 Refunds .................................................................................................................................. 393 Refunds: How It Works ........................................................................................................... 393 Reversals ................................................................................................................................ 394 Reversals: How It Works ......................................................................................................... 394 Debit Routing .......................................................................................................................... 395 Debit Routing: How It Works ................................................................................................... 395 Debit Routing: Merchant Requirements .................................................................................. 396 PINless Debit .......................................................................................................................... 397 PINless Debit Transaction Types ............................................................................................ 398 PINless Debit Transaction Matching Criteria ........................................................................... 400 PINless Debit Transaction Types and Requirements .............................................................. 402 PIN-Based Debit and EBT ...................................................................................................... 410 PIN-Based Debit and EBT Transaction Types ........................................................................ 410 PIN-Based Debit Transaction Matching Criteria ..................................................................... 412 PIN-Based Debit and EBT Transaction Types and Requirements ........................................... 414 PIN-Based Debit for EBT Only Transaction Types and Requirements .................................... 420 PINless BIN File Management ................................................................................................ 422 PINless BIN File Management: How It Works ......................................................................... 422 PINless BIN File Management: Sending Transactions ............................................................ 423 PINless BIN File Management Transaction Types and Requirements .................................... 424 Additional References ............................................................................................................. 429 Card Types / Supported Currencies ........................................................................................ 429 Response Reason Codes ....................................................................................................... 429 To Get Started ........................................................................................................................ 429 APPENDIX M: BILL ME LATER .............................................................................................. 430 Introduction ............................................................................................................................. 430 How It Works .......................................................................................................................... 430 Merchant Requirements .......................................................................................................... 430 Transaction Types and Requirements ..................................................................................... 431 Card Types / Supported Currencies ........................................................................................ 433

© Paymentech, LLC. All rights reserved x November 12, 2017

Response Reason Codes ....................................................................................................... 433 To Get Started ........................................................................................................................ 433 APPENDIX N: BILL ME LATER PRIVATE LABEL .................................................................. 434 Introduction ............................................................................................................................. 434 How It Works .......................................................................................................................... 434 Merchant Requirements .......................................................................................................... 434 Transaction Types and Requirements ..................................................................................... 435 Card Types / Supported Currencies ........................................................................................ 437 Response Reason Codes ....................................................................................................... 437 To Get Started ........................................................................................................................ 437 APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION ............................... 438 Introduction ............................................................................................................................. 438 Page Encryption CNP and Tokenization ................................................................................ 439 How It Works – Page Encryption and Tokenization ................................................................. 441 Required Fields ....................................................................................................................... 443 Test and Production URLs ...................................................................................................... 444 JavaScript Example - getkey.js ............................................................................................... 445 JavaScript Example - encryption.js ......................................................................................... 446 Test Output to Merchant Web Server ...................................................................................... 451 getkey.js Return Fields ............................................................................................................ 451 How It Works –Tokenization Only ........................................................................................... 452 Sample Tokens for Tokenization ............................................................................................. 453 Safetech Tokenization Format Examples ................................................................................ 454 Supported Action Codes ......................................................................................................... 455 Supported Methods of Payment (MOPs) ................................................................................. 456 Page Encryption CNP with FPE Transaction Types and Requirements ................................. 457 Page Encryption CNP with eFPE Transaction Types and Requirements ............................... 459 Tokenization Transaction Types and Requirements ................................................................ 461 Additional References ............................................................................................................. 462 Card Types / Supported Currencies ........................................................................................ 462 Response Reason Codes ....................................................................................................... 462 To Get Started ........................................................................................................................ 462 APPENDIX P: GIFT CARD ....................................................................................................... 463 Introduction ............................................................................................................................. 463 How It Works .......................................................................................................................... 463 Merchant Initiated Authorization Reversals ............................................................................. 464 Transaction Types and Requirements ..................................................................................... 465 Additional References ............................................................................................................. 485 Card Types / Supported Currencies ........................................................................................ 485 Response Reason Codes ....................................................................................................... 485 To Get Started ........................................................................................................................ 485 APPENDIX Q: MONEYPAK ..................................................................................................... 486 Introduction ............................................................................................................................. 486 How It Works .......................................................................................................................... 486 Transaction Matching Criteria ................................................................................................. 486 Transaction Types and Requirements ..................................................................................... 487 Card Types / Supported Currencies ........................................................................................ 495 Response Reason Codes ....................................................................................................... 495 To Get Started ........................................................................................................................ 495 APPENDIX R: HEALTH BENEFIT CARDS .............................................................................. 496 Introduction ............................................................................................................................. 496 How It Works .......................................................................................................................... 496 Examples ................................................................................................................................ 497 Transaction Types and Requirements ..................................................................................... 499

© Paymentech, LLC. All rights reserved xi November 12, 2017

Additional References ............................................................................................................. 501 Card Types / Supported Currencies ........................................................................................ 501 Response Reason Codes ....................................................................................................... 501 To Get Started ........................................................................................................................ 501 APPENDIX S: PAYPAL ............................................................................................................ 502 Introduction ............................................................................................................................. 502 How It Works .......................................................................................................................... 502 Field Specific Information ........................................................................................................ 502 Payment Actions ..................................................................................................................... 503 Transaction Types and Requirements ..................................................................................... 504 Online Format Examples ......................................................................................................... 522 Card Types / Supported Currencies ........................................................................................ 536 Response Reason Codes ....................................................................................................... 536 To Get Started ........................................................................................................................ 536 APPENDIX T: SOFT MERCHANT INFORMATION AND MERCHANT DESCRIPTOR ............ 537 Introduction ............................................................................................................................. 537 Formatting Rules (All MOPs – Non-ECP) ................................................................................ 537 Soft Merchant Information ....................................................................................................... 538 Merchant Descriptor ................................................................................................................ 539 Soft Merchant and Merchant Descriptor - Rules ...................................................................... 540 American Express ................................................................................................................... 542 Discover, Discover Diners, and JCB for U.S. Merchant Processing U.S. Currency ................. 549 JCB (Non-U.S. Merchants Processing Non-U.S. Currency) .................................................... 553 International Maestro, MasterCard, and MasterCard Canadian Restricted Debit ..................... 554 ChaseNet , Visa, and Visa Canadian Domestic Restricted Debit ............................................ 558 PINless, PIN-Debit and Electronic Benefits Transfer (EBT) .................................................... 562 Additional References ............................................................................................................. 564 Soft Merchant Information Card Types / Supported Currencies .............................................. 564 Merchant Descriptor Card Types / Supported Currencies ....................................................... 564 Response Reason Codes ....................................................................................................... 564 To Get Started ........................................................................................................................ 564 Sample Batch Worksheet ........................................................................................................ 565 Sample Online Worksheet....................................................................................................... 565 APPENDIX U: TEST ENVIRONMENT ...................................................................................... 566 How It Works .......................................................................................................................... 566 Response Reason Code ......................................................................................................... 566 Address Verification Response Code ...................................................................................... 566 Card Security Value Response Code ...................................................................................... 567 Cardholder Authentication ....................................................................................................... 567 Partial Authorizations .............................................................................................................. 567 Bill Me Later ............................................................................................................................ 567 ChaseNet ................................................................................................................................ 567 PayPal .................................................................................................................................... 567 Additional References ............................................................................................................. 568 To Get Started ........................................................................................................................ 568 APPENDIX V: LEVEL 2 AND LINE ITEM LEVEL DATA ......................................................... 569 APPENDIX W: AMERICAN EXPRESS .................................................................................... 570 Introduction ............................................................................................................................. 570 Card Acceptor Network (CAPN) .............................................................................................. 570 Legacy .................................................................................................................................... 572 Additional References ............................................................................................................. 572 Card Types / Supported Currencies ........................................................................................ 572 Authorization Response Codes ............................................................................................... 573 To Get Started ........................................................................................................................ 573

© Paymentech, LLC. All rights reserved xii November 12, 2017

APPENDIX X: ELECTRONIC CHECK PROCESSING (ECP) .................................................. 574 Introduction ............................................................................................................................. 574 How It Works .......................................................................................................................... 575 POP/ARC Transactions .......................................................................................................... 580 Transaction Types and Requirements – Non POP/ARC Transactions .................................... 581 Transaction Types and Requirements – POP/ARC Transactions ............................................ 599 Additional References ............................................................................................................. 616 Card Types / Supported Currencies ........................................................................................ 616 Response Reason Codes ....................................................................................................... 616 To Get Started ........................................................................................................................ 616 APPENDIX Y: ACCOUNT UPDATER ...................................................................................... 617 APPENDIX Z: RETAIL ............................................................................................................. 618 Introduction ............................................................................................................................. 618 How It Works .......................................................................................................................... 618 Transaction Types and Requirements ..................................................................................... 618 Additional References ............................................................................................................. 619 Card Types / Supported Currencies ........................................................................................ 619 Response Reason Codes ....................................................................................................... 619 To Get Started ........................................................................................................................ 619 APPENDIX AA: MASTERCARD IDENTIFICATION OF PRE AND FINAL AUTHORIZATIONS ................................................................................................................................................. 620 Introduction ............................................................................................................................. 620 How It Works .......................................................................................................................... 620 Transaction Types and Requirements for Pre-authorizations .................................................. 623 Transaction Types and Requirements for Final Authorizations ................................................ 625 Card Types / Supported Currencies ........................................................................................ 626 Response Reason Codes ....................................................................................................... 626 To Get Started ........................................................................................................................ 626 APPENDIX AB: ACCOUNT VERIFICATION ............................................................................ 627 Introduction ............................................................................................................................. 627 How It Works .......................................................................................................................... 627 Transaction Types and Requirements ..................................................................................... 628 Card Types / Supported Currencies ........................................................................................ 629 Response Reason Codes ....................................................................................................... 629 To Get Started ........................................................................................................................ 629 APPENDIX AC: FRAUD FILTERS ........................................................................................... 630 Introduction ............................................................................................................................. 630 Card Number Prefix ................................................................................................................ 631 Card Number .......................................................................................................................... 632 Issuing Country ....................................................................................................................... 633 Merchant Requirements .......................................................................................................... 634 How It Works .......................................................................................................................... 634 Additional References ............................................................................................................. 635 Card Types / Supported Currencies ........................................................................................ 635 Response Reason Codes ....................................................................................................... 635 To Get Started ........................................................................................................................ 635 APPENDIX AD: SHOP WITH POINTS ..................................................................................... 636 Introduction ............................................................................................................................. 636 How It Works .......................................................................................................................... 636 Transaction Types and Requirements ..................................................................................... 637 Card Types / Supported Currencies ........................................................................................ 645 Response Reason Codes ....................................................................................................... 645 To Get Started ........................................................................................................................ 645 APPENDIX AE: SAFETECH FRAUD TOOLS .......................................................................... 646

© Paymentech, LLC. All rights reserved xiii November 12, 2017

Introduction ............................................................................................................................. 646 How It Works .......................................................................................................................... 646 Fraud Analysis Only ................................................................................................................ 646 Supported MOPs and Corresponding Action Codes - Online .................................................. 647 Fraud Status Codes ................................................................................................................ 650 Transaction Types and Requirements ..................................................................................... 654 Transaction Types and Requirements ..................................................................................... 657 Additional References ............................................................................................................. 660 Card Types / Supported Currencies ........................................................................................ 660 Response Reason Codes ....................................................................................................... 660 To Get Started ........................................................................................................................ 660 APPENDIX AF: THIRD PARTY VENDOR AUTHORIZATION LOGS AND DEPOSITS – MERCHANT SERVICES PLATFORMS.................................................................................... 661 APPENDIX AG: VOYAGER ..................................................................................................... 662 APPENDIX AH: WRIGHT EXPRESS (WEX) ............................................................................ 663 APPENDIX AI: LODGING AND VEHICLE RENTAL ................................................................ 664 APPENDIX AJ: CARD TYPE INDICATORS ............................................................................ 665 Introduction ............................................................................................................................. 665 How It Works .......................................................................................................................... 665 Use Cases .............................................................................................................................. 666 Transaction Types and Requirements ..................................................................................... 668 Card Types / Supported Currencies ........................................................................................ 669 Response Reason Codes ....................................................................................................... 669 To Get Started ........................................................................................................................ 669 APPENDIX AK: AIRLINES ....................................................................................................... 670 APPENDIX AL: CHASENET .................................................................................................... 671 Introduction ............................................................................................................................. 671 How It Works .......................................................................................................................... 671 How It Works – PIN-Based Debit ............................................................................................ 672 Certification ............................................................................................................................. 672 Additional References ............................................................................................................. 672 Card Types / Supported Currencies ........................................................................................ 672 Response Reason Codes ....................................................................................................... 672 To Get Started ........................................................................................................................ 672 APPENDIX AM: CONSUMER DIGITAL PAYMENT TOKEN .................................................... 673 Introduction ............................................................................................................................. 673 How It Works .......................................................................................................................... 673 Transaction Types and Requirements – American Express and JCB ...................................... 681 Transaction Types and Requirements – American Express and JCB ...................................... 682 Transaction Types and Requirements – Discover ................................................................... 693 Transaction Types and Requirements – MasterCard .............................................................. 705 Transaction Types and Requirements – MasterCard using MST ........................................... 716 Transaction Types and Requirements – MasterCard – DTVC ................................................. 717 Transaction Types and Requirements – ChaseNet and Visa .................................................. 719 Transaction Types and Requirements – ChaseNet and Visa using MST................................ 728 Transaction Types and Requirements – ChaseNet and Visa - DTVV ...................................... 729 Card Types / Supported Currencies ........................................................................................ 731 Response Reason Codes ....................................................................................................... 731 To Get Started ........................................................................................................................ 731 APPENDIX AN: CHASE PAY ................................................................................................... 732 Introduction ............................................................................................................................. 732 How It Works - Chase Pay E-Commerce ................................................................................ 732 How It Works – Chase Pay POS Using the Chase App – Show Processing ........................... 734 How It Works – Chase Pay POS Using the Merchant App – Show Processing ....................... 735

© Paymentech, LLC. All rights reserved xiv November 12, 2017

How It Works – Chase Pay POS Using the Chase App – Scan Processing ............................ 736 How It Works – Chase Pay POS Using the Merchant App – Scan Processing ........................ 737 How It Works – Chase Pay POS Using the Merchant App – In App Processing...................... 738 Transaction Types and Requirements - Chase Pay E-Commerce.......................................... 739 Transaction Types and Requirements - Chase Pay POS ....................................................... 752 Online Format Examples ......................................................................................................... 758 Batch Format Examples .......................................................................................................... 760 Additional References ............................................................................................................. 766 Card Types / Supported Currencies ........................................................................................ 766 Response Reason Codes ....................................................................................................... 766 To Get Started ........................................................................................................................ 766 APPENDIX AO: DIRECT PAY .................................................................................................. 767 Introduction ............................................................................................................................. 767 How It Works .......................................................................................................................... 768 Transaction Types and Requirements for AFT ........................................................................ 769 Transaction Types and Requirements for OCT ....................................................................... 772 Card Types / Supported Currencies ........................................................................................ 774 Response Reason Codes ....................................................................................................... 774 To Get Started ........................................................................................................................ 774 APPENDIX AP: CHIP EMV® .................................................................................................... 775 Introduction ............................................................................................................................. 775 How It Works .......................................................................................................................... 775 Transaction Types and Requirements ..................................................................................... 779 Additional References ............................................................................................................. 780 Card Types / Supported Currencies ........................................................................................ 780 Response Reason Codes ....................................................................................................... 780 To Get Started ........................................................................................................................ 780 APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS ....... 781 Introduction ............................................................................................................................. 781 How It Works .......................................................................................................................... 781 Real World Examples .............................................................................................................. 790 Transaction Types and Requirements ..................................................................................... 798 Additional References ............................................................................................................. 799 Card Types / Supported Currencies ........................................................................................ 799 Response Reason Codes ....................................................................................................... 799 To Get Started ........................................................................................................................ 799 APPENDIX AR: ACCESS FX Cross Currency ........................................................................ 800 Introduction ............................................................................................................................. 800 How It Works .......................................................................................................................... 800 Card Types ............................................................................................................................. 807 Supported Currencies ............................................................................................................. 807 Response Reason Codes ....................................................................................................... 807 To Get Started ........................................................................................................................ 807

© Paymentech, LLC. All rights reserved 1 November 12, 2017

RECORD LAYOUTS Introduction The Merchant Services format was developed for merchants and vendors

who want to use our online payment processing services. This format allows merchants and vendors to use only the records that are needed for their business.

A length and a data type follow the position column in the detail record. Additional processing formats do not utilize the position field; however, the length and data type columns follow the same standard. The data type is either A (alphanumeric) or N (numeric only).

It is not necessary to wait for a response before sending the next transaction to Merchant Services. The merchant’s order number should be used to match responses with requests.

Allow at least two hours before depositing an authorized transaction. This allows the transaction data to load into our batch system databases so we do not send the transaction for reauthorization.

All fields are required unless otherwise stated.

All alpha characters should be in uppercase letters.

Merchant Services supports standard ASCII characters only.

Only one Format Indicator of each type can be sent on a transaction unless otherwise specified or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Both input and return records must end with a carriage return (↵).


RECORD LAYOUTS, (Continued)

Online Processing Detail Record

Position Length Data Type Field Name Comments

1 1 A Record Type Constant "P"

2,3 2 N Format Constant

Constant "74"

4 1 A Format Constant

Constant "V"

5,26 22 A Merchant’s Order Number

A value composed of any alpha, blank, digit or punctuation combination that returns in the transaction response. This field ties the request on the merchant’s end to the response Merchant Services provides you.

Left justified/blank filled Notes: Merchant Services looks at the entire 22-byte order number; however, the number of bytes that should be unique is based on the association.

Merchants should pass the same order number on authorization, deposit, and refund transactions. The order number should also remain the same for any individual authorization or deposit transaction that must be re-sent.

Debit transactions can only use upper and lower case alpha (A–Z, a–z) and numeric (0–9).

Gift Card transactions MUST pass the same order number on authorization, redemption and reversal.

MoneyPak utilizes the first 15 characters of this field. Merchants MUST pass the same order number on authorization, redemption and reversal transactions for MoneyPak.

Pay Pal utilizes the first 16 characters of this field.

Continued on next page



Online Processing Detail Record, (Continued)


Merchant’s Order Number, (Continued)

Notes, (Continued): North American (U.S. and Canada) American Express (U.S. only), ChaseNet (U.S. only), Discover and Discover Diners settled, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit utilize all 22 characters of this field. Discover and Discover Diners conveyed transactions utilize the first 16 characters of this field. American Express utilizes the first nine characters of this field for Canada. DO NOT USE the following characters: pipe (|), caret (^), percent symbol (%), backslash (\), or forward slash (/). International International Maestro, MasterCard, and Visa utilize the first 13 characters of this field. American Express utilizes the first 12 characters of this field.

DO NOT USE the following characters: caret (^), backslash (\), open bracket ([), closed bracket (]), tilde (~), or accent key ( ` ) or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

27,28 2 A Method of Payment (MOP)

Defines the MOP associated with this transaction. Valid values:

AX – American Express BL – Bill Me Later (aka PayPal Credit) BP – Bill Me Later Private Label C9 – Shop with Points CR – ChaseNet - Signature Debit/Prepaid CX – ChaseNet PIN-Based Debit CZ – ChaseNet - Credit DD – Discover Diners DE – Generic PIN-Based Debit DI – Discover DP – Generic PINless Debit






Method of Payment (MOP), (Continued)

Valid values, (Continued): EB – Electronic Benefits Transfer EC – Electronic Check (non-encrypted and

encrypted accounts) ED – European Direct Debit EN – Encryption IM – International Maestro JC – JCB MC – MasterCard MR – MasterCard Canadian Domestic Restricted

Debit MP – MoneyPak PY – PayPal SV – Gift Card VI – Visa VR – Visa Canadian Domestic Restricted Debit

Notes: The encryption MOP (EN) must be used in conjunction with the encryption flag for credit card transactions only. Electronic Check MOP (EC) must be used for all ECP transactions, whether encrypted or not.

For merchants enabled for ChaseNet MOP reassignment, when transactions are sent with MOP = VI, MOP = CR, CX or CZ could be returned in the reply record.

If card prefix 30, 36, 38, or 39 is sent as Discover, MasterCard, or MasterCard Canadian Domestic Restricted Debit, Merchant Services processes and report the transaction as Discover Diners.

MOP = DD is returned in the reply records.

For U.S. merchants processing non-USD currency or Canadian merchants processing in non-Canadian currency, if card prefix 36 is sent as MasterCard Merchant Services rejects the transaction with Response Reason Code 239 (Invalid MOP for Transaction Division).







Notes, (Continued): If card prefix 6759 or 6767 are sent as UK Domestic Maestro, Merchant Services processes and reports the transaction as International Maestro. MOP = IM is returned in the reply record.

For Action Code = PA:

The generic PINless Debit MOP (DP) must be sent for all PINless Debit transactions or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

The generic PIN-Based Debit MOP (DE) must be sent for all PIN-Based Debit transactions or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

MOP = VR should only be used by Canadian domiciled merchants processing Canadian issued cards. When these accounts are sent with MOP = VI, Merchant Services processes and reports the transaction as Visa Canadian Domestic Restricted Debit. MOP = VR is returned in the reply records. MOP = MR should only be used by MasterCard domiciled merchants processing Canadian issued cards. When these accounts are sent with MOP = MC, Merchant Services processes and reports the transaction as MasterCard Canadian Domestic Restricted Debit. MOP = MR is returned in the reply records. Gramm Leach Bliley Act The encryption MOP (EN) must be used in conjunction with the encryption flag for credit card transactions only. Electronic Check MOP (EC) must be used for all ECP transactions, whether encrypted or not. For additional methods of payment processing, please contact your Merchant Services Representative.






29,47 19 A Account Number

Account number.

Left justified/blank filled

Notes: Gramm Leach Bliley Act encrypted credit card numbers are 16 – 19 positions.

Safetech Page Encryption eFPE account numbers are 19 positions.

U.S. ECP account numbers are not greater than 17 positions or the transaction rejects with Response Reason Code 755 (No Account/ Unable to Locate).

Canadian ECP account numbers are not greater than 12 positions.

Both U.S. and Canadian ECP account numbers allow upper case alpha (D and S), numeric (0–9), dash (–), and slash (/) and space ( ).

Gramm Leach Bliley Act encrypted ECP numbers can be up to 19 positions.

Consumer Digital Payment Tokens are sent in this field.

For Bill Me Later and Bill Me Later Private Label transactions, the account number field should be populated with either the customer’s Bill Me Later account number or a Bill Me Later Bank Identification Number (BIN) (provided to the merchant by BillMeLater) followed by 10 zeros (dummy account number). The customer’s 16- byte Bill Me Later account number is returned on all approved transactions.

For Chase Pay POS (Show), this value is derived from the EMV tag 57 read from the QR code.

For Chase Pay POS (Scan), this value is derived from <track2Equivalent> from the Chase Pay Platform API GetCheckoutDataPOS2 response message.






Account Number, (Continued)

For European Direct Debit, International Bank Account Numbers (IBANs) are a maximum of 34 bytes.

For European Direct Debit, this field should be populated with a non-IBAN account number when the IBAN is not known or when the Country Code = GB.

For European Direct Debit, when the IBAN is known this field should be populated with the word “IBAN” and the IBAN must be sent in the European Direct Debit 2 Format Indicator (E2).

For European Direct Debit, if this field and the International Bank Account Number (IBAN) located on the European Direct Debit 2 Format Indicator (E2) are populated, this field is ignored.

For MoneyPak, if the Account Number is 20 bytes, this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data). The 20-byte Account Number is sent in the MoneyPak Format Indicator (MP).

For MoneyPak transactions that use Safetech Fraud Scoring, the account number can only be 19 digits. Therefore, only this field is used and the MoneyPak Format Indicator (MP) value is not sent to the Safetech fraud scoring system.

See Appendix Q: MoneyPak for additional information on populating this field.

See Appendix S: PayPal for additional information on populating this field.

Merchant Services does not MOD-10 check for Bill Me later with dummy account numbers, Debit, ECP, European Direct Debit, MoneyPak, or PayPal.






48,51 4 N Expiration Date

Account expiration date. (Optional) MMYY format. Notes: Send blanks if the card has expired since the order was placed or if the true expiration date is not known. Omitting the expiration date on a card-not-present transaction, while acceptable to ChaseNet, Discover, Discover Diners, International Maestro, JCB, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, Visa Canadian Domestic Restricted Debit, and the debit networks, may result in a decline code from the Issuer. Some Issuers decline a transaction if an invalid expiration date is sent on the transaction.

For American Express, this field must be numeric or blank filled or the transaction rejects with Response Reason Code 225 (Invalid Field Data). For Digital Wallet transactions, the expiration date should be sent or the card brand could decline the transaction. For Direct Pay transactions, this field must be sent or the transaction rejects with Response Reason Code 594 (Other Error). For MoneyPak, this field should be blank. For PayPal, this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data). For PINless Debit, this field should be blank, unless merchant is enabled for Merchant Services’ PINless Debit BIN File Management Product.






52,61 10 N Transaction Division Number

Assigned and provided to merchant by Merchant Services.

Right justified/zero filled

62,73 12 N Amount Amount of the authorization. Two decimal implied/right justified/zero filled Notes: Minimum amount for all card types is $0.01 U.S. dollars or established international currency equivalent, but no greater than the established Transaction Division limit. This field must be all zeros when Action Code = VF or the transaction rejects with Response Reason Code 202 (Bad Amount Non - Numeric Amount). Bill Me Later minimum and maximum transaction amount limits are agreed to between the merchant and BillMeLater. For Discover and Discover Diners, this field includes the Cash Back Amount Requested located on the Cash Back Format Indicator (CO). For ECP transactions processing ECP Authorization method A or P, located on the Electronic Check Processing Format Indicator (EC), the amount cannot be greater than $25,000 or the transaction rejects with Response Reason Code 202 (Bad Amount Non-Numeric Amount). For Discover, Discover Diners, MasterCard, and Visa, this field includes the Surcharge Amount located on the Order Information 7 Format Indicator (O7). If the transaction amount exceeds the default limit, the default limit must be increased in order for the transaction to process. Contact Merchant Services at 603-896-8333 prior to processing the transaction.






Amount, (Continued)

Maximum U.S. dollar amount per individual transaction: MOP Authorization American Express $9,999,999.99

ChaseNet $9,999,999.99

Discover $99,999.99

Discover Diners $99,999.99

JCB $99,999.99

MasterCard $9,999,999.99

MoneyPak $9,999.99

Other $99,999.99

PayPal $99,000.00

Shop with Points $9,999,999.99

Visa $9,999,999.99

The maximum dollar amount per transaction for JCB is applicable only to U.S. merchants processing USD currency.

74,76 3 N Currency Code

Currency code for the transaction.

Notes: This field should always be populated with the presentment currency.

See Appendix D: International Processing for all Currency Codes.






77 1 A Transaction Type

Describes the circumstances under which the transaction takes place.

Valid values: 1 – Single Transaction mail/telephone order

(MOTO) – Designates a transaction where the accountholder is not present at a merchant location and consummates the sale via the phone or through the mail. The transaction is not for recurring services or product and does not include sales that are processed via an installment plan.

2 – Recurring Transaction • Designates a transaction that

represents an arrangement between an accountholder and the merchant where transactions are going to occur on a periodic basis.

• Designates a recurring transaction conducted with a Consumer Digital Payment Token.

• Designates a transaction conducted with Chase Pay to occur on a periodic basis.

3 – Installment Transaction – Designates a group of transactions that originated from a single purchase where the merchant agrees to bill the accountholder in installments.

4 – Deferred Transaction – Designates a transaction that represents an order with a delayed payment for a specified amount of time.

5 – Secure Electronic Commerce Transaction • Designates a transaction consummated

via the Internet at a 3-D Secure capable merchant and the accountholder is fully authenticated. (e.g. 3-D Secure includes Verified by Visa and MasterCard SecureCode).

• Designates a transaction conducted with a Consumer Digital Payment Token.






Transaction Type, (Continued)

Valid values, (Continued): 6 – Non-Authenticated Electronic

Commerce Transaction – Designates a transaction consummated via the Internet at a 3-D Secure capable merchant that attempted to authenticate the accountholder using 3-D Secure (e.g. 3-D Secure includes Verified by Visa and MasterCard SecureCode). Attempts occur with Verified by Visa and MasterCard SecureCode transactions in the event of: • A non-participating Issuer • A non-participating accountholder

of a participating Issuer • A participating Issuer, but the

authentication server is not available

7 – Channel Encrypted Transaction – Designates a transaction between an accountholder and a merchant consummated via the Internet where the transaction includes the use of transaction encryption such as SSL, but authentication was not performed. The accountholder payment data was protected with a form of Internet security, such as SSL, but authentication was not performed. Also includes Chase Pay initiated transactions.







Valid values, (Continued): 8 – Non-Secure Electronic Commerce

Transaction – Designates a transaction between an accountholder and a merchant consummated via the Internet where: • the transaction does not include the

use of any transaction encryption such as SSL

• authentication is not performed • an accountholder certificate is not

managed. If "8" is sent and MOP = PY, the

transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

I – IVR Transaction (PINless Debit only) – Designates a transaction where the accountholder consummates the sale via an interactive voice response (IVR) system. If "I" is sent and MOP not equal to PINless debit, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

R – Retail Transaction – Designates a transaction where the accountholder was present at a merchant location. If "R" is sent for non-U.S. or non-Canadian transaction division, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type). If "R" is sent for a transaction with a MOTO Merchant Category Code (MCC) the transaction downgrades. If "R" is sent for a transaction with a Direct Marketing Merchant Category Code (MCC), the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).







Notes: Transaction Type is defaulted at the transaction division level. All transactions processed through the transaction division carry the default Transaction Type value unless this field is populated (population of this field overrides the transaction division level default). Transaction Type must match for both authorization and subsequent deposit. For Discover, Discover Diners, JCB, MasterCard, and Visa recurring transactions, all transactions should be sent with Transaction Type = 2. For all other MOPs, the first transaction should be sent with Transaction Type = 1, 7, I, or R (whichever is applicable). All subsequent transactions should be sent with Transaction Type = 2.

For Consumer Digital Payment Token, if the Transaction Type does not equal 2 or 5 the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

Magnetic Secure Transmission (MST) for Mobile Devices For MasterCard and Visa Consumer Digital Payment Token, Transaction Type should equal R, mag stripe data is included. Cryptogram is not applicable. Host Card Emulation (HCE) for Mobile Devices For MasterCard and Visa Consumer Digital Payment Token, Transaction Type should equal 2 or 7.







Notes, (Continued):

For Verified by Visa and MasterCard SecureCode, the ECI returned at authentication time must be supplied with the transaction.

For Chase Pay, the <eciIndicator> value returned from the Chase Pay Service must be supplied with the transaction unless the transaction is recurring.

For Chase Pay POS, all transactions should be sent with Transaction Type = R.

For ECP, this field is ignored.

For International Maestro, if the Transaction Type does not equal 1, 2, 3, 4, 5, 6, or 7, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type). However, if Transaction Type = 1, 3, or 4, the merchant domicile and card issuing country must both be France, Ireland, or Great Britain or the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

For International Maestro, if the Transaction Type = 2, and an AAV value is not sent, the transaction is processed using Transaction Type = 7.

For MoneyPak, if the Transaction Type does not equal 1, 7, or 8 the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

See Appendix L: Debit Processing for additional information on populating this field.






78,80 3 A Encryption Flag

Identifies the algorithm for Merchant Services to decrypt the account number in relation to the Gramm Leach Bliley Act or identifies the account number type for participation in Safetech Page Encryption and Tokenization. This field is required if participating in Safetech Page Encryption and Tokenization. (Optional)


Valid values for Gramm Leach Bliley Act for Credit Card:

C – Issuer C F – Issuer F 001 – Issuer 001 002 – Issuer 002 003 – Issuer 003 004 – Issuer 004 005 – Issuer 005 006 – Issuer 006 007 – Issuer 007 008 – Issuer 008 009 – Issuer 009 010 – Issuer 010 011 – Issuer 011 012 – Issuer 012 013 – Issuer 013 014 – Issuer 014 015 – Issuer 015 016 – Issuer 016 017 – Issuer 017 018 – Issuer 018 019 – Issuer 019 021 – Issuer 021 022 – Issuer 022 023 – Issuer 023 026 – Issuer 026 027 – Issuer 027 028 – Issuer 028 029 – Issuer 029






Encryption Flag, (Continued)

Valid values for Gramm Leach Bliley Act for ECP: 101 – Issuer 101 102 – Issuer 102 103 – Issuer 103 104 – Issuer 104 105 – Issuer 105 106 – Issuer 106 107 – Issuer 107 108 – Issuer 108 109 – Issuer 109 110 – Issuer 110 111 – Issuer 111 112 – Issuer 112 113 – Issuer 113

Valid values for Safetech Page Encryption and Tokenization:

201 – Incoming account number uses FPE and a token is returned

202 – Incoming account number uses eFPE and a token is returned

203 – Incoming account number is not encrypted and a token is returned

204 – Incoming account number uses a token and a token is returned

205 – Reserved for internal Merchant Services use only

Notes: Gramm Leach Bliley Act For credit card, the MOP field must be populated with either EN for encryption, or the actual card type (e.g. VI for Visa) or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

For ECP, the MOP field must be populated with EC or the transaction rejects with Response Reason Code 225 (Invalid Field Data).






Encryption Flag, (Continued)

Notes, (Continued):

Safetech Page Encryption and Tokenization If values 201 or 202 are populated, the transaction division must be enabled for page encryption and tokenization or the transaction rejects with Response Reason Code 244 (Invalid Encryption Format).

If values 201, 202, 203, or 204 are populated, a token is returned unless an error occurs. Blanks in this field indicate that the incoming account number is clear and a token is not returned.

See Appendix O: Safetech Page Encryption and Tokenization for additional information on populating this field.

Please contact your Merchant Services Representative for the appropriate value to begin using encryption.

81 1 A Payment Indicator

Payment indicator. (Optional) Valid values:

A – Aggregation (micro-payments transaction - not a bill payment transaction or a micro-merchant transaction) Note: For ChaseNet and Visa only.

D – Debt Repayment (Bill payment transaction and repayment of existing debt)

N – No (Non bill payment transaction) Y – Yes (Bill payment transaction) " " – Blank

Notes: Payment Indicator = Y and N may be defaulted at the transaction division level. However, Payment Indicator = D and A cannot be defaulted.

For debt repayment transactions in Europe and the United Kingdom, when MCC = 6012, this field should be populated with D.






Payment Indicator, (Continued)

Notes, (Continued):

Population of this field overrides the transaction division level default.

Payment Indicator must match from authorization to deposit.

Payment Indicator is not applicable for the following MCC’s:

Gas station (5541, 5542) Hotel (7011) Restaurant (5812, 5814)

82,83 2 A Action Code This action tells Merchant Services what service to perform on the transaction. Valid values:

AA – Direct Pay Account Funding Transaction (AFT) Authorization (Visa)

AO – Direct Pay Original Credit Transaction (OCT) (Visa)

AR – Authorization Reversal (American Express, ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, MasterCard Canadian Domestic Restricted Debit, PayPal, Shop with Points, Visa, Visa Canadian Domestic Restricted Debit)

AU – Authorize (Bill Me Later, Bill Me Later Private Label, Credit Card, Gift Card, PayPal, Safetech Fraud Tools, Shop with Points)

AV – Re-activation Reversal (Gift Card) Note: Amount must be 0.00.

BA – Block Activation (Gift Card) BI – Current Balance Inquiry (ChaseNet,

Discover, Discover Diners, Electronic Benefits Transfer, Gift Card, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, MoneyPak, Safetech Fraud Tools, Shop with Points, Visa, Visa Canadian Domestic Restricted Debit) Note: Amount should be 0.00.






Action Code, (Continued

Valid values, (Continued): BV – Block Activation Reversal (Gift Card) CV – Redemption Completion Reversal (Gift

Card) DR – Refund Auth Reversal (Debit,

Electronic Benefits Transfer) DV – De-activation Reversal (Gift Card) ED – Do Express Payment (PayPal, Safetech

Fraud Tools) EG – Get Express Payment (PayPal) ES – Set Express Payment (PayPal) ET – Register (Shop with Points) FA – Fraud Analysis (All supported Safetech

Fraud Tools MOPs) HC – Healthcheck (Shop with Points) IR – Issuance Activation Reversal (Gift Card) LO – Validate Only (ECP and European

Direct Debit, Safetech Fraud Tools) Notes: When MOP = ED, Amount must

be 0.00. When MOP = EC, Amount should be 0.00.

PA – Purchase Auth (Debit, Electronic Benefits Transfer, MoneyPak, Safetech Fraud Tools)

PC – Prior Voice Auth Completion (Electronic Benefits Transfer only)

PR – Purchase Auth Reversal (Debit, Electronic Benefits Transfer)

PV – Redemption Reversal (Gift Card) RA – Refund Auth (Debit, Electronic Benefits

Transfer, MoneyPak, Safetech Fraud Tools)

RC – Redemption Completion (Gift Card) RF – Refund (Gift Card) RP – Redemption (Gift Card) RV – Refund Reversal (Gift Card) SA – Add Value (Gift Card) SD – De-activation (Gift Card) Note: Amount must be 0.00.






Action Code, (Continued)

Valid values, (Continued): SI – Issuance Activation (Gift Card) SV – Re-activation (Gift Card) TN – Token Only Request (Safetech Page

Encryption and Tokenization) Note: If Encryption Flag = 204, the transaction rejects with Response Reason Code 244 (Invalid Encryption Format).

UT – Unregister (Shop with Points) VF – Account Verification (ChaseNet,

International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Safetech Fraud Tools, Visa, Visa Canadian Domestic Restricted Debit) Note: Amount must be 0.00

VO – Validate Only (formerly Validate and Verify) (ECP U.S., Safetech Fraud Tools)

Note: Amount should be 0.00. VR – Add Value Reversal (Gift Card,

Safetech Fraud Tools) W1 – Validate / Account Status Verification

(ECP U.S.) W3 – Validate / Account Status Verification /

Account Owner Authentication (ECP U.S.)

Notes: See Table 1: Action Codes Definitions

See Appendix O: Safetech Page Encryption and Tokenization for additional information.

See Appendix X: Electronic Check Processing (ECP) for additional information.

See Appendix AE: Safetech Fraud Tools for additional information.

84 1 A Reserved Reserved for internal Merchant Services use only. (Do Not Use – must remain blank)

Note: A carriage return ( ↵ ) indicates the end of a transaction and any Format Indicators must be sent before the carriage return ( ↵ ).




Table 1: Action Code Definitions

Action Code Name Definition

AA Direct Pay Account Funding Transaction (AFT) Authorization

Direct Pay Account Funding Transaction (AFT) Authorization

Authorize a transaction for the movement of funds from a ‘senders’ account to the Merchant. Currently, only supported for Visa transactions.

See Appendix AO: Direct Pay for additional information.

AO Direct Pay Original Credit Transaction (OCT)

Direct Pay Original Credit Transaction (OCT)

Issue Credit to a ‘receiver’ account originating from the Merchant. Currently, only supported for Visa transactions.

See Appendix AO: Direct Pay for additional information.

AR Authorization Reversal Reverses a prior Action Code = AU (Authorize).

Notes: The Reversal is only valid if the authorization has not expired.

See Appendix F: Authorization Reversal for specific credit card information.

See Appendix P: Gift Card for additional information.

See Appendix S: PayPal for additional information.

See Appendix AD: Shop with Points for additional information.

AU Authorize Authorize this transaction.

Notes: For Gift Card – Dollar amount is "reserved" on the card account until Action Code = RC (Redemption Completed) or Action Code = AR (Authorization Reversal) is sent.

For Gift Card – If the transaction is sent for MCC = 5542 and the amount is $1.00, the entire balance of the card is "locked". For any other MCC and/or amount, the card is "locked" for that amount. When the sale is complete, Action Code = RC (Redemption Completed) must be sent with the actual sale amount. For MCC = 5542, the authorization expires after 3 hours while all other authorizations expire after 7 days.

AV Re-Activation Reversal Reverses a prior Action Code = SV (Re-Activation).

The Gift Card server declines the transaction if the amount sent causes the card balance to go negative.




Table 1: Action Code Definitions, (Continued) Action Code Name Definition

BA Block Activation Activates up to 100 gift cards at one time.

Notes: The number of cards to be activated (not including the first card) is sent in Format Indicator FC (Gift Card). Each card is activated with the value in the Amount field.

If any card in the block of cards fails (for example: a card is already active or the card is not "owned" by the merchant) all cards up to the failed card are set to active with a $0.00 amount. The failed account number is identified in Reply Format Indicator F1 (Gift Card Block Activation).

BI Balance Inquiry Obtains the current balance on an account. BV Block Activation Reversal Reverses a prior Action Code = BA (Block

Activation).

Notes: The first card number in the series must be sent in Format Indicator FC (Gift Card), identifying the number of cards that were activated in the series. Amount must match the Amount of the original Block Activation.

If any activity has been performed on a card in the block (e.g. a redemption on one of the active cards) before the Block Activation Reversal is sent, the entire reversal fails.

CV Redemption Completion Reversal

Reverses a prior Action Code = RC (Redemption Completion).

DR Refund Authorization Reversal

Reverses a prior Action Code = RA (Refund Authorization).

DV De-activation Reversal Reverses a prior Action Code = SD (De-activation).

Note: Amount sent should be "Previous Balance" returned in the Reply Format Indicator FC (Gift Card) on the prior deactivation.

ED Do Express Payment Obtains an authorization or identifies an order that is subsequently authorized.

EG Get Express Payment Returns information about the customer including name and address that is stored at PayPal.

ES Set Express Payment Establishes a session with PayPal. Receives a token to be used for browser re-direct to PayPal for customer check out.

ET Register Enrolls an accountholder’s account in a Shop with Points program.




Table 1: Action Code Definitions, (Continued)

Action Code Name Definition

FA Fraud Analysis Performs a fraud analysis only on a transaction.

HC Healthcheck Sends a test account to verify that a Shop with Points system is functioning normally.

IR Issuance Activation Reversal

Reverses a prior Action Code = SI (Issuance Activation).


LO Validate Only ECP – Validates this transaction against an ACH eligibility file, Notification of Change (NOC) file, and ECP Internal Negative File.

Amount should be 0.00.

European Direct Debit – Refer to Appendix K: European Direct Debit for additional information.

PA Purchase Authorization Verifies accountholder’s open-to-buy and if the funds are available, debits the accountholder’s account.

PC Prior Voice Auth Completion

Verifies a previous voice authorization for an Electronic Benefits Transfer transaction. Notes: When Action Code = PC, MOP must equal EB or the transaction rejects with Response Reason Code 241 (Illegal Action). When Action Code = PC, the Prior Authorization Format Indicator (PA) must be sent or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

PR Purchase Authorization Reversal

Reverses a prior Action Code = PA (Purchase Authorization).

PV Redemption Reversal Reverses a prior Action Code = RP (Redemption). RA Refund Authorization Issues a credit to this account number.

Note: To complete the refund, Action Code = RF (Refund) must be sent in a settlement file for this transaction.





Action Code Name Definition RC Redemption Completion Indicates the redemption amount to be processed.

Used to redeem the amount processed in conjunction with a prior Action Code = AU (Authorize) request.

This is similar to Action Code = DP (Deposit) used for batch transactions.

If the Partial Redemption flag is set to "yes" and the total redemption amount is higher than the amount available on the card, the entire amount on the card is redeemed and returned in Previous Balance of the Gift Card Reply Format Indicator (FC). The merchant should subtract this amount from the sale amount to create the balance due for the customer.

If the amount sent is 0.00, the card is "unlocked". This is similar to Action Code = AR (Authorization Reversal).

RF Refund Adds the transaction Amount to the balance of an active gift card.

RP Redemption This is a one step process that authorizes and does a redemption completion on the gift card.

This is similar to Action Code = DC (Conditional Deposit) used for batch transactions. Amount of the transaction must be greater than 0.00.

RV Refund Reversal Reverses a prior Action Code = RF (Refund).


SA Add Value Adds the transaction Amount to the balance of an active gift card.

Note: Adding value to the card cannot exceed the original activation amount.

SD De-activation Inactivates a gift card account.

This Action Code can only be sent for gift cards that currently have an active status.



RECORD LAYOUTS (Continued)


Action Code

Name Definition

SI Issuance Activation Issues and activates individual gift cards.

Amount of the transaction must be greater than $0.00.

SV Re-Activation Re-activates a gift card account with a balance of the amount sent. Only allowed for a card that has been previously de-activated.

TN Token Only Request Token only request

Note: For Safetech Page Encryption and Tokenization requests a token for an account number but does not perform any other action.

UT Unregister Removes the accountholder’s enrollment in a Shop with Points program.

VF Account Verification Verify this account is valid before performing authorization.

The amount of the transaction must be $0.00.

VO Validate Only (formerly Validate and Verify)

ECP – Validates this transaction against an ACH eligibility file, Notification of Change (NOC) file, and ECP Internal Negative File. Note: Amount should be 0.00.

VR Add Value Reversal Reverses a prior Action Code = SA (Add Value). The Gift Card server declines the transaction if the amount sent causes the card balance to go negative.

W1 Validate / Account Status Verification

ECP – Validate this transaction against an ACH eligibility file, Notification of Change (NOC) file, and ECP Internal Negative File. If Validation successful, invoke the ECP - Advanced Verification Product to verify account status.

W3 Validate / Account Status Verification and Account Owner Authentication

ECP - Validate this transaction against an ACH eligibility file, Notification of Change (NOC) file, and ECP Internal Negative File. If Validation successful, invoke the ECP - Advanced Verification Product to verify account status and authenticate account owner.



Additional Request Processing Formats Additional formats required for a transaction can be sent sequentially, in any order. Below is the list of formats available. Please refer to the record layout section of each specified format for data lengths and elements. Format

Indicator Description Number of

bytes in format

Comments Record Layout Page

Number AA Customer ANI 14 Customer ANI (Automatic

Number Identification) 31

AB Bill to Address 139 Bill to Address 32 AE Employer Information 139 Employer Address 34 AG Giftee Address 139 Address of person who is

receiving the gift 36

AH Customer Host Name 62 Customer Host Name 38 AI IP Address 48 IP address 39 AL Email Address 53 Email address 40 AR Customer Browser

Name 62 Customer Browser Name 41

AS Ship to Address 139 Ship to address 42 AV01 ECP Advanced

Verification - 01 207 Additional Fields to support

Account Status Verification and Account Owner Authentication

44

AV02 ECP Advanced Verification - 02

118 Additional Fields to support Account Owner Authentication

46



48



49

AZ Postal Code Only Address

14 Minimum information required to obtain AVS

51

BD Agreement Description 5-132 Description of contract or other agreement.

52

BL Bill Me Later 53 Bill Me Later 53 BM Bill Me Later Information 94 Bill Me Later Information for all

Bill Me Later Methods of Payment

55

BP Bill Me Later Private Label

78 Bill Me Later Private Label 58

CO Cash Back 14 Cash received in addition to purchase

60

CP Chip EMV® 6-1004 Chip Card Data Format Indicator 61 CT Card Type Indicator 5 Card Type Indicator 63 DB Debit Information 47 Debit Information – PIN-Based

Debit Only 64

DA Discover Authentication 70 Discover 66 DN Digital PAN 39 Digital PAN 68 DP Direct Pay 179 Direct Pay additional data for

AFT or OCT transactions. 70




Additional Request Processing Formats, (Continued)

Format Indicator Description

Number of bytes in format Comments

Record Layout Page

Number DR Debit Routing 4 Debit routing data 76 DW Digital Wallet 6 Digital Wallet 77 E2 European Direct Debit

2 71 European Direct Debit including

IBAN 80

EBT Electronic Benefits Transfer

27 Food Stamp or Cash Benefits 84

EC Electronic Check Processing

12 Electronic Check Processing 85

ED European Direct Debit 16 European Direct Debit 86 EI Safetech Page

Encryption 45 Safetech Page Encryption 88

FC Gift Card 9 Gift Card 90 FR Fraud 7 Card Security Value (CSV) 91 FX Access FX Cross

Currency 67 Access FX Cross Currency 95

GS Goods Sold 6 Goods sold product type. 97 HN Formatted Ship To

Name 47 Formatted Ship To Name 98

II Healthcare IIAS 63 List healthcare specific amounts

99

JA JCB Authentication 82 JCB Authentication 101 KT01 Fraud Scoring 1 51 Fraud Scoring (Short) 104 KT02 Fraud Scoring 2 148 Fraud Scoring (Long) 107 KTT1 User Defined and

Shopping Cart 9-1008 Fraud Scoring – UDF and

Shopping Cart 110

LG Lodging 4 Hotel lodging information 115 LN Formatted Bill To

Name 47 Formatted Bill To Name 116

MA MasterCard Authentication

34 MasterCard SecureCode and Consumer Digital Payment Token

117

MB Mobile POS Device Information

3 Mobile POS Device Information 119

MD Merchant Descriptor 41 Merchant Descriptor 120 ME Merchant Echo 5-103 Merchant Echo 123 MP MoneyPak 67 MoneyPak information 124 MT Message Type

Records 49 Message Type Records 125

M1 Miscellaneous 1 13 Miscellaneous 1 127 OI Order Information 20 Information on specific order 128 O2 Order Information 2 27 Biller Reference Number

(PINless Debit Only) 130




Additional Request Processing Formats, (Continued)



Record Layout Page

Number O3 Order Information 3 17 Information on specific order (3) 131 O5 Order Information 5 74 Order Information 5 132 O6 Order Information 6 45 Order Information 6 133 O7 Order Information 7 10 Used for the transaction

surcharge amount 135

P4 Prior Authorization and Reversal Reason Format Indicator

23 Prior Authorization and Reversal Reason Format Indicator

136

PA Prior Authorization 22 Prior Authorization 138 PB Partial Authorization 3 Partial Authorization 140 PD Payment Device 7 Mobile POS Device Type

Indicator 142

PI Personal Information 39 Personal Information 144 PM Payment Action 3 Payment Action 146 PS Page Set Up 55-182 Page Set Up 148 P2 Personal Information 2 27 Personal Information 2 150 RD Recipient Data 32 Recipient Data 151 RE Retail 82 (Track 1)

45 (Track 2) Includes track 1 and track 2 data elements

153

RI Request Information 6 Request Information 156 RV Reversal – Gift Card 5 - 103 Reversal – Gift Card 157 R2 Retail 2 15 Retail 2 160 R3 Retail 3 9 - 84 Varying length data track 163 SM Soft Merchant

Information 139 Soft Merchant Information 166

ST Split Tender 3 Split Tender 168 S2 Soft Merchant

Information 2 144 Soft Merchant Information 2 169

S3 Soft Merchant Information 3

176 Soft Merchant Information 3 173

S4 Soft Merchant Information 4

204 Soft Merchant Information 4 178

TI Token ID 22 Token ID 183 US URL and Address Flag 12-522 URL and Address Flag 184 VA Visa Authentication 82 Verified by Visa and Consumer

Digital Payment Token 186

VT Various Text 5-94 Various Text 190 VV Spectrum SDK 6 Reserved for Internal Merchant

Services use only N/A

XA American Express Authentication

82 American Express Consumer Digital Payment Token

191




Additional Request Processing Formats, (Continued) Notes: For all non-retail transactions, full address (Format Indicator AB) or zip code (Format Indicator AZ) is needed to qualify for the best interchange rate. Whenever possible, Merchant Services recommends that merchants send the full address.

Retail manually keyed transactions require address information (zip code at a minimum) in order to qualify for the best possible interchange rate.

For Bill Me Later/Bill Me Later Private Label transactions – If sending only a billing address, Merchant Services assumes the billing address and shipping address are the same and conveys that to BillMeLater. There is no interchange rate for Bill Me Later transactions.



Customer ANI Format Indicator (AA)

Length Data Type Field Name Comments

2 A Format Indicator "AA" Constant – Customer ANI information. Specifies this record as an additional processing format of the Merchant Services standard format.

10 A Customer ANI (Automatic Number Identification)

ANI specified phone number that the customer used to place the order with the merchant.


Notes: This field should be sent when the transaction is a phone order and Safetech fraud scoring is requested.

If Customer ANI is not supported by the call center populate this field with “0123456789.”

2 A Customer ii Digits Customer information identifier. (Optional)

Note: Telephone company-provided ANI ii (Information Identifier) coding digits associated with Customer ANI phone number that correspond to call type; e.g., cellular, government, institution, etc.

Note: This Format Indicator is recommended when the transaction is a phone order and Safetech Fraud Scoring is requested.

Sample 8 9 56789012345678 AA603896600000



Bill to Address Format Indicator (AB)


2 A Format Indicator "AB" Constant – Bill to address information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Telephone Type Telephone type. (Optional)

Valid values: D – Day H – Home N – Night W – Work

Note: This field is required if Telephone Number is populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

14 A Telephone Number The accountholder’s phone number. (Optional)

AAAEEENNNNXXXX format where:

AAA = Area Code EEE = Exchange NNNN = Number XXXX = Extension

30 A Name Text Accountholder’s name. (Optional)


Notes: An asterisk should precede the last name.

For Gift Card, only alpha (A – Z) and numeric (0 – 9) can be sent.

Sending the Formatted Bill To Name Format Indicator (LN) overrides this field.

30 A Address Line 1 Accountholder’s address information. (Optional)







Bill to Address Format Indicator (AB), (Continued)


2 A Country Code Accountholder’s country code. (Optional)

Note: See Appendix B: Address Verification for additional information on populating this field.

20 A City Accountholder’s city. (Optional)


2 A State Accountholder’s state. (Optional)


10 A Postal Code Accountholder’s postal code. (Optional)

Left justified/blank filled Notes: Address Line 2, if populated, is used for address verification locale matching; otherwise Address Line 1 is used.

For American Express address verification, Address Line 1 and/or Address Line 2, Name Text, and Telephone Number fields cannot be populated with all zeros and/or slashes, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

International Issuers prefer complete bill to address information.

Multiple forms of Bill to Address format indicators should not be sent. If the merchant has a complete bill to address, they should send the Bill to Address Format Indicator. If the merchant only has the bill to postal code, they should send the Postal Code Only Address Format Indicator. If a merchant sends in both format indicators, the last format indicator sent is used for Address Verification.

This Format Indicator is recommended when Safetech fraud scoring is requested.

Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 ABH6038968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 PO BOX 92 USSALEM NH03079



Employer Information Format Indicator (AE)


2 A Format Indicator "AE" Constant – Employer address information. Specifies this record as an additional processing format of the Merchant Services standard format.




14 A Telephone Number Employer’s phone number. (Optional)



30 A Name Text Employer’s name. (Optional)


30 A Address Line 1 Employer’s address information. (Optional)


28 A Address Line 2 Employer’s address information. (Optional)


2 A Country Code Country code. (Optional)

Valid values: US – United States CA – Canada GB – Great Britain UK – United Kingdom " " – Blanks




Employer Information Format Indicator (AE), (Continued)


20 A City Employer’s city. (Optional)


2 A State Employer’s state. (Optional)


10 A Postal Code Employer’s postal code. (Optional)


Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 AED6032378846 ATLAS STEEL COMPANY 427 EAST MAIN STREET

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 PO BOX 623 USMANCHESTER NH03072



Giftee Information Format Indicator (AG)


2 A Format Indicator "AG" Constant – Giftee address information. Specifies this record as an additional processing format of the Merchant Services standard format.




14 A Telephone Number Phone number of the person receiving the gift. (Optional)



30 A Name Text Name of person receiving gift. (Optional)


Note: Asterisk should precede last name.

30 A Address Line 1 Giftee’s address information. (Optional)


28 A Address Line 2 Giftee’s address information. (Optional)





Giftee Information Format Indicator (AG), (Continued)


2 A Country Code Country code. (Optional)

Valid values: US – United States CA – Canada GB – Great Britain UK – United Kingdom " " – Blanks

20 A City Giftee’s city. (Optional)


2 A State Giftee’s state. (Optional)


10 A Postal Code Giftee’s postal code. (Optional)


Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 AGH6035558849 JAN *SMITH 21 MAIN STREET

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 USSALEM NH03079



Customer Host Format Indicator (AH)


2 A Format Indicator "AH" Constant – Customer host information. Specifies this record as an additional processing format of the Merchant Services standard format.

60 A Customer Host Name Name of the server to which the customer is connected.


Example: PHX.QW.YYY.COM

Sample 8 9 0 1 2 3 4 56789012345678901234567890123456789012345678901234567890123456 AHPHX.QW.YYY.COM



IP Address Format Indicator (AI)


2 A Format Indicator "AI" Constant – IP address information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Address Subtype Type of address.

Valid value: B – Bill To/Buyer Address

45 A Customer IP Address Customer’s IP address.


Notes: Characters are acceptable (e.g. dots).

Recommended for Safetech fraud scoring. If this field is not sent, a default value is used.

Note: This Format Indicator is recommended when the transaction is a web order and Safetech fraud scoring is requested.

Sample 8 9 0 1 2 3 567890123456789012345678901234567890123456789012 AIB10.10.1.2



Email Address Format Indicator (AL)


2 A Format Indicator "AL" Constant – Email address information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Address Subtype Type of email address.

Valid values: B – Bill To/Buyer Email Address G – Giftee Email Address

Note: "B" should be sent for PayPal transactions.

50 A Email Address Email address.


Notes: Characters are acceptable (e.g. dots).

Should be sent for Safetech fraud scoring. If the merchant does not send an email address, a default value is used.

Notes: Only one Email Address Format Indicator can be sent for each Address Subtype on a transaction. An Address Subtype = B and/or Address Subtype = G can be sent for a transaction; however, multiple format indicator records of either Address Subtype = B or Address Subtype = G for a transaction is not allowed.

BillMeLater requests this data be sent for all Bill Me Later transactions (Merchant Services does not front-end reject the transaction if it is not present). BillMeLater may decline the transaction without this information.


Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901234567 [email protected]



Customer Browser Format Indicator (AR)


2 A Format Indicator "AR" Constant – HTTP browser type information. Specifies this record as an additional processing format of the Merchant Services standard format.

60 A Customer Browser Name

Customer HTTP browser type.


Example: MOZILLA/4.0 (COMPATIBLE; MSIE 5.0; WINDOWS 95)

Note: This Format Indicator is recommended when the transaction is a web order and Safetech fraud scoring is requested.

Sample 8 9 0 1 2 3 4 56789012345678901234567890123456789012345678901234567890123456 ARMOZILLA/4.0 (COMPATIBLE; MSIE 5.0; WINDOWS 95)



Ship to Address Format Indicator (AS)


2 A Format Indicator "AS" Constant – Ship to address information. Specifies this record as an additional processing format of the Merchant Services standard format.




14 A Telephone Number Phone number for ship to recipient. (Optional)



30 A Name Text Ship to name. (Optional)


Note: An asterisk should precede the last name.

30 A Address Line 1 Ship to address information. (Optional)




2 A Country Code Ship to country code. (Optional)

20 A City Ship to city. (Optional)





Ship to Address Format Indicator (AS), (Continued)


2 A State Ship to state. (Optional)


10 A Postal Code Ship to postal code. (Optional)


Notes: For American Express address verification, Address Line 1 and/or Address Line 2, Name Text, and Telephone Number fields cannot be populated with all zeros and/or slashes, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

For PayPal transactions, PayPal declines the transaction if the Ship to Address is outside the U.S.


Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 ASD6038968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 PO BOX 92 USSALEM NH03079



ECP Advanced Verification 1 Format Indicator (AV01)


4 A Format Indicator "AV01" Constant – ECP Advanced Verification information. Specifies this record as an additional processing format of the Merchant Services standard format.

40 A First Name Account owner first name. (Optional)


Notes: This field is required when MOP = EC, Action Code = W3, and the Last Name field is supplied, or the transaction rejects with Response Reason Code of 752 (Missing Name). This field is required when MOP = EC, Action Code = W3, and the Business Name field is blank, or the transaction rejects with Response Reason Code 752 (Missing Name).

40 A Last Name Account owner last name. (Optional)


Notes: This field is required when MOP = EC, Action Code = W3, and the First Name field is supplied, or the transaction rejects with Response Reason Code of 752 (Missing Name). This field is required when MOP = EC, Action Code = W3, and the Business Name field is blank, or the transaction rejects with Response Reason Code 752 (Missing Name).

40 A Middle Name or Initial

Account owner middle initial or middle name. (Optional)


Note: If middle initial, do not use a period.

87 A Business Name Account owner business name. (Optional)


Notes: This field is required when MOP = EC, Action Code = W3, and the First Name and Last Name fields are blank, or the transaction rejects with Response Reason Code 752 (Missing Name).




ECP Advanced Verification 1 Format Indicator (AV01), (Continued)

Notes: This Format Indicator is specific to the Account Owner’s Authentication Service which is a part of the ECP Advanced Verification product. Account Owner’s Authentication Service is only applicable for Action Code = W3. This Format Indicator must be sent when MOP = EC and Action Code = W3 or the transaction rejects with Response Reason Code 752 (Missing Name).

If both the account owner business name and the account owner name (along with the other account owner matching fields) are to be verified, the merchant must send in two separate transactions. This Format Indicator is ignored when MOP does not equal EC. See Appendix X: Electronic Check Processing (ECP) for more details regarding the Advanced Verification actions and the resulting responses.

Sample 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456789 AV01JOHN Q PU

7 8 9 0 1 2 3 4 01234567890123456789012345678901234567890123456789012345678901234567890123456789 BLIC A BUSINESS NAME

5 6 7 8 9 012345678901234567890123456789012345678901234567






40 A Address Line 1 First line of account owner address or business address. (Optional) Left justified/blank filled

40 A Address Line 2 Second line of account owner address. (Optional) Left justified/blank filled

25 A City Account owner city. (Optional) Left justified/blank filled

2 A State Account owner state. (Optional) Left justified/blank filled

10 A Zip Account owner zip code. (Optional)


Valid zip code formats: NNNNN NNNNNNNNN NNNNN-NNNN

Note: Merchant Services does not edit check the values in this field.

1 A Phone Type Account owner telephone type. (Optional)

Valid values: H – Home W – Work " " – Blanks

Note: Home phone (H) is the default value.

10 A Phone Account owner phone number as designated on the Phone Type field. (Optional) Note: Merchant Services does not edit check the values in this field.





Notes: This Format Indicator is specific to the Account Owner’s Authentication Service which is a part of the ECP Advanced Verification product. Account Owner’s Authentication Service is only applicable for Action Code = W3. This Format Indicator is ignored when MOP does not equal EC. This Format Indicator should not be sent when both the First Name and Last Name fields as well as Business Name field, located on the ECP Advanced Verification 1 Format Indicator (AV01), are sent. The Early Warning System is not able to distinguish between personal and business data elements. Therefore, when both the personal name and business name are submitted along with other Account Owner fields, the transaction rejects with Response Reason Code 225 (Invalid Field Data). See Appendix X: Electronic Check Processing (ECP) for more details regarding the Advanced Verification actions and the resulting responses.

Sample 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456789 AV021ST STREET 2ND STREET A

7 8 9 0 1 01234567890123456789012345678901234567890123456 CITY ST12345 H1234567890






15 N Check Serial Number Check number. (Optional) Right justified/zero filled

Note: This field is required when Action Code = W1 or W3, and the ECP Authorization Method = A or P on the Electronic Check Processing Format Indicator (EC),or the transaction rejects with Response Reason Code 247 (Check Conversion Data Error).

Notes: This Format Indicator is specific to the Account Owner’s Authentication Service which is a part of the ECP Advanced Verification product. This Format Indicator must be sent when MOP = EC, Action Code = W1 or W3, and the ECP Authorization Method = A or P from the Electronic Check Processing Format Indicator (EC), or transaction rejects with Response Reason Code 227 (Missing Companion Data) This Format Indicator is ignored when MOP does not equal EC. See Appendix X: Electronic Check Processing (ECP) for more details regarding the Advanced Verification actions and the resulting responses.

Sample 8 9 0 5678901234567890123 AV03000001234567890






4 N Tax Identification Number (TIN)

Last four digits of the account owner Social Security number or of the business Tax Identification Number. (Optional) Note: Merchant Services does not edit check the values in this field.

8 N DOB Account owner date of birth. (Optional)

YYYYMMDD Format

Note: Merchant Services does not edit check the values in this field.

1 A ID Type Type of identification associated with the account owner identification number. (Optional)

Valid values: 0 – Driver’s License USA 1 – Military USA 2 – Passport 3 – Resident Alien ID 4 – State identification 5 – Student identification 6 – Driver’s License foreign 7 – Driver’s License Canada 8 – Driver’s License Mexico 9 – Other primary ID foreign A – Matricula Consular card B – South America Cedula No. " " – Blank Note: This field is required when the Action Code

= W3 and the ID Number field is populated, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

28 A ID Number Identification number of the account owner. (Optional)

Left justified/blank filled Continued on next page





6 A ID State State of issue for the identification. (Optional) Left justified/blank filled

Notes: This Format Indicator is specific to the Account Owner’s Authentication Service which is a part of the ECP Advanced Verification product. This Format Indicator must be sent when ECP Advanced Verification 1 Format Indicator (AV01), is sent, or the transaction rejects with a Response Reason Code of 225 (Invalid Field Data). If this Format Indicator is sent when both the First Name and Last Name as well as Business Name field, located on the ECP Advanced Verification 1 Format Indicator (AV01), are sent, the transaction rejects with a Response Reason Code of 225 (Invalid Field Data). This Format Indicator is ignored when MOP does not equal EC. The Early Warning System is not able to distinguish between personal and business data elements. Therefore, when both the personal name and business name are submitted along with other Account Owner fields, the transaction rejects with Response Reason Code 225 (Invalid Field Data). See Appendix X: Electronic Check Processing (ECP) for more details regarding the Advanced Verification actions and the resulting responses.

Sample 8 9 0 1 2 3 5678901234567890123456789012345678901234567890123456789 AV048321197012240



Postal Code Only Address Format Indicator (AZ)


2 A Format Indicator "AZ" Constant – Postal code only address information. Specifies this record as an additional processing format of the Merchant Services standard format.

10 A Postal Code Accountholder’s Postal code. (Optional)


2 A Country Code Accountholder’s Country code. (Optional)

Note: See Appendix B: Address Verification for additional information on populating this field.

Notes: International issuers prefer complete bill to address information.

Multiple forms of Bill to Address Format Indicators should not be sent. If the merchant has a complete bill to address, they should send the Bill to Address Format Indicator. If the merchant only has the bill to postal code, they should send the Postal Code Only Address Format Indicator. If a merchant sends in both format indicators, the last format indicator sent is used for Address Verification.

Sample 8 9 56789012345678 AZ03079 US



Agreement Description Format Indicator (BD)


2 A Format Indicator "BD" Constant – Agreement description information. Specifies this record as an additional processing format of the Merchant Services standard format.

3 N Length of Next Field Indicates the number of positions submitted for the following field:

Valid values: 001 – 127

Variable 001-127

A Agreement Description Description of contract or other agreement.

Note: The Agreement Description is only sent to PayPal when Action Code = ES and Payment Action Format Indicator (PM) Subtype Flag = B, C, or E.

Sample 8 9 0 1 56789012345678901234567890 BD021AGREEMENT DESCRIPTION



Bill Me Later Format Indicator (BL)


2 A Format Indicator "BL" Constant – Bill Me Later information. Specifies this record as an additional processing format of the Merchant Services standard format.

8 N Shipping Cost Total shipping cost of customer purchase. (Optional)

Two decimal implied/right justified/zero filled

5 N T&C Version The Terms & Conditions version number agreed to by the customer. (Optional)


8 N Customer Registration Date

Date customer registered with merchant. (Optional)

YYYYMMDD format

2 A Customer Type Flag New or existing customer with merchant. (Optional)


Valid values: E – Existing N – New

4 N Item Category Product description code assigned by BillMeLater. (Optional)


16 A Pre-approval Invitation Number

Indicates whether or not customer has been pre-approved. (Optional)


Notes: Pre-approval from credit bureau should include the 16 digit pre-approval number. This allows the pre-approval to be matched with the first customer order.

Internal pre-approvals should include the leftmost digit as a 1.

Pre-approvals should not include all zeros or be blank filled.




Bill Me Later (BML) Format Indicator (BL), (Continued)


4 A Merchant Promotional Code

Merchant promotional code. (Optional)


1 A Customer Password Change

Indicates if customer has changed password at merchant site. (Optional)

Valid values: Y – Password has been changed N – No change to password

1 A Customer Billing Address Change

Indicates if customer has updated billing address at merchant site. (Optional)

Valid values: Y – Billing address has been updated N – No change to billing address

1 A Customer Email Change

Indicates if customer has updated email address at merchant site. (Optional)

Valid values: Y – Email address has been updated N – No change to email address

1 A Customer Home Phone Change

Indicates if customer has updated phone number at merchant site. (Optional)

Valid values: Y – Phone number has changed N – No change to phone number

Note: This Format Indicator can only be sent when MOP = BL or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901234567 BL000000100010220040930E 54001234567123456789



Bill Me Later Information Format Indicator (BM)


2 A Format Indicator "BM" Constant – Bill Me Later information. Specifies this record as an additional processing format of the Merchant Services standard format.



5 N T&C Version Terms & Conditions version number agreed to by the customer. (Optional)




YYYYMMDD format









Notes: Pre-approvals from a credit bureau should include the 16 digit pre-approval number. This allows the pre-approval to be matched with the first customer order.

Internal pre-approvals should include the leftmost digit as a one.





Bill Me Later Information Format Indicator (BM), (Continued)





1 A Customer Password Change

Indicates if customer has changed password at merchant site. (Optional)

Valid values: Y – Password has been changed N – No change to password

1 A Customer Billing Address Change

Indicates if customer has updated billing address at merchant site. (Optional)

Valid values: Y – Billing address has been updated N – No change to billing address

1 A Customer Email Change

Indicates if customer has updated email address at merchant site. (Optional)

Valid values: Y – Email address has been updated N – No change to email address

1 A Customer Home Phone Change

Indicates if customer has updated phone number at merchant site. (Optional)

Valid values: Y – Phone number has changed N – No change to phone number

2 A Product Type Product type assigned by BillMeLater. (Optional)

2 A Secret Question Code Used for customer authentication. Indicates question to be answered in the Secret Answer field. (Optional)





Bill Me Later Information Format Indicator (BM), (Continued)


25 A Secret Answer Used for customer authentication in conjunction with the Secret Question Code. Indicates customer’s reply to the secret question. May be used to pass driver’s license or soundex#. (Optional)


10 A IATA Number Travel Agency Identification. The IATA number is currently seven digits. (Optional)


1 A Customer Authenticated by Merchant

Customer authenticated by merchant. (Optional)

Valid values: Y – Yes N – No

1 A Back Office Processing Indicates if the transaction is system generated (not initiated by the customer). (Optional)


Note: This Format Indicator can only be sent when MOP = BL or BP or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 BM000000250010220061230N 00291234567891234567FAL YYNY99A AAAAAAAAAAAAAAAAAA

6 7 0123456789012345678 AAAAAAA1245678 YY



Bill Me Later Private Label Format Indicator (BP)


2 A Format Indicator "BP" Constant – Bill Me Later private label information. Specifies this record as an additional processing format of the Merchant Services standard format.



5 N T&C Version Terms & Conditions version number agreed to by the customer. (Optional)




YYYYMMDD format









Bill Me Later Private Label Format Indicator (BP), (Continued)





Notes: Pre-approval from credit bureau should include the 16 digit pre-approval number. This allows the pre-approval to be matched with the first customer order.

Internal pre-approvals should include the leftmost digit as a 1.





2 A Product Type Product type assigned by BillMeLater. (Optional)


2 A Secret Question Code Used for customer authentication. Indicates question to be answered in the Secret Answer field. (Optional)


25 A Secret Answer Used for customer authentication in conjunction with the Secret Question Code. Indicates customer's reply to the secret question. May be used to pass driver’s license or soundex#. (Optional)


Note: This Format Indicator must be sent when MOP = BP or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 1 2 3 4 5 6 567890123456789012345678901234567890123456789012345678901234567890123456789012 BP000000100010220040930E 54001234567123456789 AB



Cash Back Format Indicator (CO)


2 A Format Indicator "CO" Constant – Cash back information. Specifies this record as an additional processing format of the Merchant Services standard format.

12 N Cash Back Amount Requested

Amount requested by the customer to be returned as cash.


Note: When MOP = DD or DI and the Cash Back Amount Requested is greater than the total transaction amount the transaction rejects with Response Reason Code 268 (Invalid Cash Back Amount).

Notes: This Format Indicator can only be sent when MOP = DD or DI or when MOP = MC or DD and the card prefix = 30, 36, 38, or 39 is sent by a U.S. merchant processing USD currency, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

If Transaction Type is not equal to R (Retail), the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

Sample 8 0 56789012345678 CO000000002000



Chip EMV® Data Format Indicator (CP)


2 A Format Indicator

"CP" Constant – Chip EMV® data information. Specifies this record as an additional processing format of the Merchant Services standard format.

3 N Size of Chip Data

3 byte ASCII header that contains the overall length of the expanded ASCII version of the binary encoded data. Maximum length allowed is 999.

Right justified/zero filled, 1-999 A Chip Data Contains several EMV/Contactless tags represented in the

BER-TLV format.

Variable up to 999.

Left justified

Chase Pay POS (Show) This field must be populated with the EMV tags and values read from the QR code.

Chase Pay POS (Scan) This field must be populated with the <paymentInfo2> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

Notes: Send this Format Indicator if the authorization contains EMV® data.

If this Format Indicator is sent when Transaction Type does not equal R, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

Merchants should send any and all data received.

EMV data between card and device is generally in binary format, commonly referred to as BER-TLV (Basic Encoding Rules-Tag Length Value). It must be converted to ASCII format by the merchant prior to submitting to Merchant Services. All data must be submitted in single byte ASCII.

See Appendix AP: Chip EMV®.



Chip EMV® Data Format Indicator (CP), (Continued) Non-Chase Pay EMV data between card and device is generally in binary format, commonly referred to as BER-TLV (Basic Encoding Rules-Tag Length Value). It must be converted to ASCII format by the merchant prior to submitting to Merchant Services. All data must be submitted in single byte ASCII.

Chase Pay POS EMV data is received by the merchant (either QR code or <PaymentInfo2>) encoded in Base 64 characters. This must be converted to Hexadecimal representation (i.e. ASCII 0-9,A-F) and submitted in the Chip Data field. If EMV tag 97FC is not present the transaction rejects with Response Reason Code 285 (Customer Exclusive Data (CED) Missing).

Sample 8 9 56789 CP001



Card Type Indicator Format Indicator (CT)


2 A Format Indicator "CT" Constant – Card type indicator information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 N Format Version Defines the Reply Format Indicator to be returned. Valid values:

01 – Reply Format Indicator CT01 is returned 02 – Reply Format Indicator CT02 is returned

1 A Reserved Blank Notes: This Format Indicator is required when a merchant wishes to receive Card Type Indicator information.

If this Format Indicator is sent and the MOP does not equal CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR, the transaction rejects with Response Reason Code 241 (Illegal Action).

If this Format Indicator is sent and Action Code does not equal AU, BI, or VF, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

See Appendix AJ: Card Type Indicator for additional information.

Sample 8 56789 CT01



Debit Information Format Indicator – PIN-Based Debit Only (DB)


2 A Format Indicator "DB" Constant – Debit information. Specifies this record as an additional processing format of the Merchant Services standard format.

16 A Encrypted PIN Number Encrypted PIN number entered by customer.


16 A PIN Key Sequence Number (KSN)

Key sequence number (from the PIN pad).


1 A Account Type Account type.

Valid values: C – Checking (Canada) S – Savings (Canada) " " – Blank for all U.S. transactions

Notes: If populated for U.S. transactions, this field is ignored.

If not populated for Canada, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

12 N Cash Back Amount Amount customer has requested for cash back.


Notes: If the Account Type = F, located on the Electronic Benefits Transfer Format Indicator (EBT), and this field is not 0.00, the transaction rejects with Response Reason Code 225 (Invalid Field Data). Zero fill this field if no cash back requested.




Debit Information Format Indicator – PIN-Based Debit Only (DB), (Continued)

Notes: When sending this Format Indicator, MOP must be a PIN-Based Debit MOP, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This Format Indicator must be sent when Action Code = DR, PA, PR, or RA, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator must be sent when MOP = EB, except when Action Code = PC and cash back is not requested, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

When sending this Format Indicator, either the Retail (RE) or the Retail 3 (R3) Format Indicator must be sent or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901 DBPINPIN KEYKEY 000000000000



Discover Authentication Format Indicator (DA)


2 A Format Indicator "DA" Constant – Discover authentication information. Specifies this record as an additional processing format of the Merchant Services standard format.

28 A Cardholder Authentication Verification Value (CAVV)

Consumer Digital Payment Token Unique transaction cryptogram generated by the merchant’s digital wallet provider. Left justified/blank filled

Notes: Must be sent in Base 64 Encoding or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

DO NOT MANIPULATE this value in any way.

For original authorizations, this field is required and must be a valid Base 64 value.

For subsequent authorizations (i.e., split/delayed shipments), this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For recurring authorizations, Transaction Type must equal 2 and this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

40 A Reserved Blanks




Discover Authentication Format Indicator (DA), (Continued)

Notes: This Format Indicator can only be sent when MOP = DI or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Consumer Digital Payment Token When using this Format Indicator the Transaction Type field must be populated with a “2” or a “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

Sample for Discover CDPT 8 9 0 1 5678901234567890123456789012345678 DAgodlOEAxmL4wH7108KtV0QkAQAS=Rx1o



Digital PAN Format Indicator (DN)


2 A Format Indicator "DN" Constant – Consumer Digital Payment Token information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Token Assurance Level

Token assurance level. (Optional)

1 A Account Status Status of the token BIN. (Optional) Valid values:

N – Unregulated R – Regulated “ “ – blanks

Note: Only used for Visa transactions.

11 N Token Requestor ID Token requestor identifier. (Optional)

Chase Pay E-Commerce This field must be populated with the <tokenRequestorID> value returned from the Chase Pay Service.

If this field is not populated, the transaction will not be considered a Chase Pay transaction and may not process.

Chase Pay POS (Show) This field must be populated with the value received in EMV tag 9F19 read from the QR code.

Chase Pay POS (Scan) This field must be populated with the <tokenRequestorID> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

Note: When transaction is Chase Pay the MOP field must be populated with CR, CZ or VI or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

23 A Reserved Blanks




Digital PAN Format Indicator (DN), (Continued)

Notes: This format indicator can be sent when a Consumer Digital Payment Token is sent in the Account Number field of the Online Processing Detail Record. When MOP = DI, this information is not sent to Discover. See Appendix AM: Consumer Digital Payment Token for more information.

Chase Pay E-Commerce

This Format Indicator must be sent for Chase Pay transactions and the Token Requestor ID field must be populated with the <tokenRequestorID> value returned from the Chase Pay Service.

When using this Format Indicator the Transaction Type field must be populated with a 2 (for recurring transactions) or the <eciIndicator> value returned from the Chase Pay Service, or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

Chase Pay POS (Show) This Format Indicator must be sent for Chase Pay transactions, and the Token Requestor ID field must be populated with the value received in EMV tag 9F19 read from the QR code. When using this Format Indicator, the Transaction Type must be populated with an R, or the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

Chase Pay POS (Scan) This Format Indicator must be sent for Chase Pay transactions, and the Token Requestor ID field must be populated with the <tokenRequestorID> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

When using this Format Indicator, the Transaction Type must be populated with an R, or the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

See Appendix AN: Chase Pay for more information.

Sample 8 9 0 1 2 567890123456789012345678901234567890123 DNA1



Direct Pay Format Indicator (DP)


2 A Format Indicator "DP" Constant – Direct Pay information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Business Application Identifier

Specifies the Direct Pay transaction type.

Valid values:

AA – Business to Person Valid Action Codes: • AA • AO

PP – Person to Person Valid Action Codes: • AA • AO

LO – Loyalty and Offers Valid Action Codes: • AO

CP – Card Bill Payment Valid Action Codes: • AO

FD – Funds Dispersement Valid Action Codes: • AO

GD – Government Disbursement Valid Action Codes: • AO

MD – Merchant Disbursement Valid Action Codes: • AO

TU – Top Up (pre-paid card loads) Valid Action Codes: • AO





Business Application Identifier, (Continued)

Valid values, (Continued):

BI – Bank Initiated Valid Action Codes: • AO

WT – Wallet Transfer Valid Action Codes: • AA • AO

Note: This field must sent when MOP = VI and Action Code = AA or AO, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

12 N Service Fee Fee assessed to process transaction. (Optional)

Two decimal implied/right justified/zero filled or blanks

Note: Only used when MOP = VI and Action Code = AA.

12 N Foreign Exchange Markup Fee

Fee assessed when presentment and settlement currencies do not match. (Optional)


Note: Only used when MOP = VI and Action Code = AA.




Direct Pay Format Indicator (DP), (Continued)


16 A Sender Reference Number

A transaction reference number provided by the originating bank that uniquely identifies the sender. (Optional)


Notes: This field must be sent when MOP = VI and Action Code = AO or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Should not contain the Sender Account Number.

2 N Source of Funds Source of funds provided from sender to the Merchant. (Optional)

Valid values:

01 – Visa Credit 02 – Visa Debit 04 – Cash 05 – Debit/deposit access accounts

other than those linked to a Visa card (includes checking/savings accounts and proprietary debit/ATM cards).

06 – Credit accounts other than those linked to a Visa card (includes credit cards and proprietary credit lines)

“ “ – Blanks


Note: This field is must be sent when MOP = VI and Action Code = AO or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

30 A Recipient Name Name of the credited accountholder. (Optional)


Notes: This field must be sent when MOP = VI and Action Code = AO or the transaction rejects with Response Reason Code 227 (Missing Companion Data).






30 A Sender Name Sender name. (Optional)



35 A Sender Address Sender’s street address. (Optional)



25 A Sender City Sender’s primary city. (Optional)

Left justified/blank filled.


2 A Sender State The state or province of the sender’s primary state. (Optional)








9 A Sender Zip Code Sender’s primary residential zip code (postal). (Optional)


Note: Only used when MOP = VI and Action Code = AO.

2 A Sender Country Code Country associated with the sender’s primary residential address. (Optional)

Left justified/space filled.

Notes: This field is must be sent when MOP = VI and Action Code = AO or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Must be a valid 2-character ISO 3166 standard country code or the transaction rejects with Response Reason Code 238 (Invalid Currency).





Notes: This Format Indicator must sent when MOP = VI and Action Code = AA or AO, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If this Format Indicator is sent and Action Code is not equal to AA or AO, the transaction rejects with Response Reason Code 241 (Illegal Action).

This Format Indicator can only be sent when MOP = VI, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

If this Format Indicator is sent and the transaction MCC is not equal to 4829, the transaction rejects with Response Reason Code 249 (Invalid MCC).

If this Format Indicator is sent with a value of BI in the Business Application Identifier field and the transaction MCC is not equal to 6012, this transaction rejects with Response Code 225 (Invalid Field Data).

When Action Code = AA or AO, the merchant’s Transaction Division must be enabled for Direct Pay Account Funding Transaction (AFT) or the transaction rejects with Response Reason Code 241 (Invalid Action).

If this Format Indicator is sent for OCT, Soft Merchant Information Format Indicators SM, S2, S3, or S4 should be sent for the transaction.

If this Format Indicator is sent and the Transaction Type is not equal to 5, 6, 7, or R, the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

When this Format Indicator is sent and the transaction division country is not equal to US, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

See Appendix AO: Direct Pay for additional information on populating this record.

Samples

AFT Authorization 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890 DPAA0000000000000000000000001234567890123456

7 8 9 0 1 2 3 123456789012345678901234567890123456789012345678901234567890123456789012

OCT Transaction 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890 DPAO 123456789012345601123456789012345678921234567893

7 8 9 0 1 2 3 123456789012345678901234567890123456789012345678901234567890123456789012 123456789012345678921234567893123451234567890123456789212345121234567812



Debit Routing Format Indicator (DR)


2 A Format Indicator "DR" Constant –Debit Routing information. Specifies this record as an additional processing format of the Merchant Services standard format.

42 A Debit Routing Data

Valid Debit MOP chosen for Message Directed Routing.

Note: There are an additional 40 bytes of spaces in this field to accommodate additional debit networks. Currently, only the first two bytes are used for specifying the Debit MOP routing.

Sample 8 5678 DRMC



Digital Wallet Format Indicator (DW)


2 A Format Indicator "DW" Constant –Digital Wallet information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Digital Wallet Indicator Indicates if a digital wallet is used. MasterCard Staged Digital Wallet and Visa Checkout Valid values:

0 - No 1 - Yes

" " - Blank Note: For MasterCard Staged Digital Wallet, this field should be populated if the transaction division flag is set to “Self”. Visa Digital Wallet Valid values:

3 - Visa Staged Digital Wallet Note: If the Staged Digital Wallet transactions flag is not enabled on the transaction division level, do not send this format indicator for Visa Staged Digital Wallet transactions. If the merchant does not include this format indicator and the flag is not set, the transaction rejects with Response Reason Code 225 (Invalid Field Data).




Digital Wallet Format Indicator (DW), (Continued)


MasterCard Digital Wallet Valid values:

2 - MasterPass wallet initiated transaction or

Non- MasterPass wallet initiated transaction (transaction with non-Risk Based authentication types)

4 - Non-SecureCode transaction with Merchant Risk Based Decision

5 - Non-SecureCode transaction with Issuer Risk Based Decision

6 - Non-SecureCode MasterPass transaction with Merchant’s own Risk Based Decisioning

7 - Partial shipment or recurring transaction

3 A MasterPass Digital Wallet ID (WID)

MasterPass Wallet Identifier. (Optional) Left justified\blank filled Notes: If the Digital Wallet Indicator field is populated with a 4, 5, or 6, this field should be populated.

If the Digital Wallet Indicator field is populated with a 2, and this is a MasterPass wallet initiated transaction, this field should be populated.

This field cannot be all zeros or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

For Staged Digital Wallet transactions this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

If MOP = VI, this field is populated with blanks.




Digital Wallet Format Indicator (DW), (Continued)

Notes:

MasterCard Staged Digital Wallet This Format Indicator should only be sent when the transaction division is enabled for MasterCard Digital Wallet.

Visa Staged Digital Wallet This Format Indicator should only be sent when the transaction division is enabled for Visa Digital Wallet.

MasterCard Staged Digital Wallet, Visa Staged Digital Wallet, Visa Checkout, and MasterPass This Format Indicator can only be sent if MOP = IM, MC, MR, CR, CZ, VI, or VR or the transaction rejects with Response Reason Code 241 (Illegal Action).

For MasterPass transactions, this Format indicator is only sent to MasterCard when the indicator is “2” and a WID is present. All other cards brands process as BAU even if they were initiated from MasterPass.

For Visa Checkout transactions, this Format Indicator is only sent to Visa when the Digital Wallet Indicator value = 1.

See Appendix J: MasterCard Digital Wallet for additional information on populating this Format Indicator.

Sample 8 9 567890 DW1



European Direct Debit 2 Format Indicator (E2)


2 A Format Indicator "E2" Constant – European direct debit information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Country Code Customer’s bank country code. Valid values:

AT – Austria BE – Belgium CY – Cyprus DE – Germany ES – Spain FI – Finland FR – France GB – United Kingdom GR – Greece IE – Ireland IT – Italy

LU – Luxembourg MC – Monaco MT – Malta NL – Netherlands PT – Portugal SI – Slovenia SK – Slovak Republic




European Direct Debit 2 Format Indicator (E2), (Continued)


10 A Bank Sort Code Customer’s bank sort code. Left justified/blank filled

Notes: If the IBAN field is not populated, this value must be valid for the country or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number).

If the IBAN field is not populated, and Country Code = FR, this field should contain the data for both Bank Sort Code and Bank Branch Code without spaces between the two numbers.

If the IBAN field is not populated, this field must be sent when Country Code = AT, CY, DE, ES, FI, FR, GB, GR, IE, IT, MC, MT, PT, SI, SK, or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number). If the IBAN field is populated, this field is ignored when the Country Code is not equal to GB.

2 A RIB Code Bank account checksum. (Optional) Right justified/zero filled or blanks

Notes: If the IBAN field is not populated, this field must be sent when Country Code = ES, FR, IT, MC, or PT, or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number).

If the IBAN field is populated, this field is ignored when the Country Code is not equal to GB.

10 A Bank Branch Code Customer’s specific bank branch. (Optional) Left justified/blank filled

Note: If the IBAN field is not populated, this field must be populated when Country Code = ES, GR, IT, MC, or PT, or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number). For all other Country Codes, this field is ignored.






34 A IBAN Customer’s International Bank Account Number (IBAN) (Optional)

Left justified/blank filled Notes: If this field is populated and the Country Code does not equal “GB”, the BIC (Bank Identifier Code) is required or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

When Country Code = GB this field is ignored.

If this field is populated, the Bank Sort Code, Bank Branch Code, RIB Code, and Account Number fields are ignored.

11 A BIC Customer’s Bank Identifier Code (BIC) (Optional)

Left justified/blank filled Notes: This field must be populated when IBAN is populated and Country Code is not equal to GB or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This field must be populated with an 8 or 11 byte value or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number).

When Country Code = GB this field is ignored.

If this field and the IBAN field are populated, the Bank Sort Code, Bank Branch Code, RIB Code, and Account Number fields are ignored.





Notes: This Format Indicator or European Direct Debit Format Indicator (ED) must be sent when MOP = ED or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

If this Format Indicator and European Direct Debit Format Indicator (ED) are both sent the transaction rejects with Response Reason Code 204 (Other Error). The European Direct Debit 2 Reply Format Indicator (E2) is returned when MOP = ED and an IBAN, located on the European Direct Debit 2 Format Indicator (E2), is populated.

The European Direct Debit 2 Reply Format Indicator (E2) is returned when MOP = ED and the transaction division flag is enabled to return IBAN information and the transaction is not rejected.

See Appendix K: European Direct Debit for additional information on populating this Format Indicator.

Sample 8 9 0 1 2 3 4 5 56789012345678901234567890123456789012345678901234567890123456789012345 E2AT 123456789123456789123456789123456798765432



Electronic Benefits Transfer Format Indicator (EBT)


3 A Format Indicator "EBT" Constant – Electronic Benefits Transfer information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Account Type Account type Valid values:

C – Cash benefits F – Food stamps

Notes: When Action Code = DR, PR, or RA, MOP = EB, and this field is populated with C, the transaction rejects with Response Reason Code 241 (Illegal Action). When Action Code = BI, DR, PA, PR, or RC, MOP = EB, and this field is populated with F, the transaction rejects with Response Reason Code 241 (Illegal Action).

15 A Voucher Number Electronic Benefits Transfer voucher number. Left justified/blank filled

8 A Food and Consumer Number (FCN)

Merchant Food and Consumer Number (FCN). (Optional) Note: If Account Type = C, this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Note: This Format Indicator must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Sample 8 0 1 2 567890123456789012345678901 EBTF123ABC1



Electronic Check Processing Format Indicator (EC)


2 A Format Indicator "EC" Constant – Electronic check information. Specifies this record as an additional processing format of the Merchant Services standard format.

9 N RDFI/Bank ID Routing number of the receiving financial institution.


Notes: Also referred to as ABA # or Transit Routing #.

The Receiving Depository Financial Institution (RDFI) number is nine bytes in length. (U.S. only)

A Canadian Bank ID number is eight bytes in length and should not have a space " " or dash "-". Canadian checks typically display the Branch Number before the Financial Institution. The proper formatting of this field is FFFBBBBB where F is Financial Institution and B is Branch Number.

1 A ECP Authorization Method

Identifies the method used by accountholders to authorize debits to their accounts. (Optional)

Valid values: A – Accounts Receivable (ARC) (US Only) I – Internet (WEB) P – Point of Purchase (POP) (US Only) T – Telephone (TEL) W – Written (PPD) " " – Blank

Note: Population of this field overrides the transaction division level default.

Note: This Format Indicator must be sent when MOP = EC or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample

8 9 56789012345 EC012345678



European Direct Debit Format Indicator (ED)


2 A Format Indicator "ED" Constant – European direct debit information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Country Code Customer’s bank country code.

Valid values: AT – Austria BE – Belgium CY – Cyprus DE – Germany ES – Spain FI – Finland FR – France GB – United Kingdom GR – Greece IE – Ireland IT – Italy

LU – Luxembourg MC – Monaco MT – Malta NL – Netherlands PT – Portugal SI – Slovenia SK – Slovak Republic

10 A Bank Sort Code Customer’s bank sort code.


Notes: If the IBAN field located on the European Direct Debit 2 Format Indicator (E2) is not populated, this value must be valid for the country or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number). If the IBAN field located on European Direct Debit 2 Format Indicator (E2) is not populated, and Country Code = FR, this field should contain the data for both Bank Sort Code and Bank Branch Code without spaces between the two numbers.




European Direct Debit Format Indicator (ED), (Continued)


2 A RIB Code Bank account checksum. (Optional) Right justified/zero filled or blanks

Note: Must be provided for France or the transaction rejects with Response Reason Code 750 (Invalid Transit Routing Number).

Notes: This Format Indicator or European Direct Debit 2 Format Indicator (E2) must be sent when MOP = ED or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Merchant Services recommends sending European Direct Debit 2 Format Indicator (E2) instead of this Format Indicator.

If this Format Indicator and European Direct Debit 2 Format Indicator (E2) are both sent the transaction rejects with Response Reason Code 204 (Other Error).

The European Direct Debit 2 Reply Format Indicator (E2) is returned when MOP = ED and the transaction division flag is enabled to return IBAN information and the transaction is not rejected.

See Appendix K: European Direct Debit for additional information on populating this Format Indicator.

Sample 8 9 0 5678901234567890 EDGB012345



Safetech Page Encryption Format Indicator (EI)


2 A Format Indicator "EI" Constant – Safetech Page Encryption information. Specifies this record as an additional processing format of the Merchant Services standard format.

12 A Subscriber ID The subscriber identifier for FPE/eFPE transactions. This value is assigned by Merchant Services.

Notes: The value in the Encryption Flag field in Online Processing Detail Record must be 201 or 202 or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

The value in this field must match the value defined for the Transaction Division, or the transaction rejects with Response Reason Code 280 (Invalid Token Subscriber ID).

4 A Format ID Format code used for FPE/eFPE transactions.


Valid values: 64 – Preserve first 6 and last 4 60 – Preserve first 6 04 – Preserve last 4 00 – No preservation " " – Blanks

Note: If this field is not blank, the value in the Encryption Flag field in Online Processing Detail Record must be 201 or 202 or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

16 A Integrity Check Validates that the Subscriber ID and Format ID received matches what was sent.

Notes: This value is returned as output to the customer browser from a one-time key request (encryption.js).

The value in the Encryption Flag field in Online Processing Detail Record must be 201 or 202 or the transaction rejects with Response Reason Code 227 (Missing Companion Data).




Safetech Page Encryption Format Indicator (EI), (Continued)


10 A Key ID The key identifier for FPE transactions.


Notes: Not required for eFPE transactions.

If this field is populated, the value in the Encryption Flag field in the Online Processing Detail Record must be 201 or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

1 A Phase ID The phase Identifier for FPE transactions.

Notes: Not required for eFPE transactions.

If this field is populated, the value in the Encryption Flag field in Online Processing Detail Record must be 201 or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Notes: This Format Indicator is used for Safetech Page Encryption only. If the Encryption Flag field in the Online Processing Detail Record is not equal to 201 or 202 this Format Indicator is ignored. See Appendix O: Safetech Page Encryption and Tokenization for additional information.

Sample for FPE 8 9 0 1 2 567890123456789012345678901234567890123456789 EI12345678901264 ABCDEFGHIJKLMNOP12345ABCDEA

Sample for eFPE 8 9 0 1 2 567890123456789012345678901234567890123456789 EI12345678901264 ABCDEFGHIJKLMNOP



Gift Card Format Indicator (FC)


2 A Format Indicator "FC" Constant – Gift Card information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Partial Redemption Indicator Flag

Determines approval functionality for Gift Card authorizations. (Optional)

Valid values: Y – Transaction is allowed if authorization

amount is greater than current balance. N – Transaction is declined if authorization

amount is greater than current balance.

4 A Reserved Blanks

2 N Number of Cards for Block Activation

Indicates the number of cards to be activated within a block activation transaction. (Optional)


Notes: This Format Indicator must be sent when Action Code = BA or BV or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator can be sent when Action Code = BA, BI, RC, RF, RP, SA, SD, SI, and SU.

Sample 8 9 567890123 FCY 10



Fraud Format Indicator (FR)


2 A Format Indicator "FR" Constant – Card security value information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Card Security Presence

Used to validate the presence of a card security value.

Valid values: 1 – Value is present (BP, CR, CZ, DD, DI,

IM, JC, MC, MR, VI, or VR) Notes: Merchants must send “1” when providing the Dynamic Token Verification Value (DTVV). Merchants must also send “1” when providing the Dynamic Token Verification Code (DTVC).

2 – Value is on card, but illegible (BP, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR)

5 – CVV2 not provided for Safetech Page Encryption transaction (AP, AX, CR, CZ, DD, DI, DP, IM, JC, MC, MR, NP, PP, SP, SV, VI, or VR)

9 – Accountholder states that the card has no card security value (BP, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR)

" " – Blank, indicator not sent (AX, BP, IM, MC, MR, or SV)

Notes: This field should be blank for American Express and Gift Card. If populated, it is ignored.

When this field = 5, the value in the Encryption Flag field in Online Processing Detail Record should be 201 or 202.




Fraud Format Indicator (FR), (Continued)


4 A Card Security Value Used to identify the card security value provided by the accountholder.


Notes: It is against regulations to store this value.

American Express CID and Gift Card CVD2 values are four bytes in length.

Bill Me Later Private Label VAK, ChaseNet CVV2, Discover, Discover Diners, and JCB CID, MasterCard, International Maestro CVC2, and Visa CVV2 values are three bytes in length.

For Gift Card, if the Card Security Value field is populated, it is passed to the Gift Card system, regardless of the Action Code.

For Safetech Page Encryption, this field should contain the encrypted card security value unless Card Security Presence = 5.

Safetech Page Encryption requires both the account number and card security value be encrypted. This field should be an encrypted blank value when Card Security Presence = 5.

Safetech Page Encryption eFPE uses 4 bytes.

For original and subsequent authorizations using DTVV, this field must contain the DTVV cryptogram and the Card Security Presence field must equal “1”. However, for recurring transactions, merchants must send the static cryptogram instead of the DTVV value. The static cryptogram should be populated in the Cardholder Authentication Verification Value (CAVV) field, located in the Visa Authentication Format Indicator (VA).






4 A Card Security Value, (Continued)

Notes, (Continued): For original and subsequent authorizations using DTVC, this field must contain the DTVC cryptogram and the Card Security Presence field must equal “1”. However, for recurring transactions, merchants must send the static cryptogram instead of the DTVC value. The static cryptogram should be populated in the Accountholder Authentication Value (AAV) field, located in the MasterCard Authentication Format Indicator (MA).

For token based transactions that are authenticated with Verified by Visa/3-D Secure, the DTVV value should be sent in the Card Security Value field in conjunction with the CAVV field.





Notes: If not populating Card Security Value and Card Security Presence fields, do not send this Format Indicator.

This Format Indicator must be sent when Encryption Flag, located on the Online Processing Detail Record is equal to 201 or 202, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator is only applicable for MOP = JC when a merchant is domiciled in the U.S. and is processing USD currency.

Merchants domiciled in Great Britain, processing a Visa Great Britain issued card, must send this Format Indicator to avoid additional fees.

For key entered transactions, sending this Format Indicator may protect the transaction against chargebacks.

See Appendix E: Card Security Verification for information on populating these fields.


Samples:

Amex Gift Card All Others 8 9 5678901 FR 9876

8 9 5678901 FR 4321

8 9 5678901 FR1321

Sample with eFPE: Amex 8 9 5678901 FR 9jHo



ACCESS FX Cross Currency Format Indicator (FX)


2 A Format Indicator "FX" Constant – ACCESS FX Cross Currency information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Opt-out Indicator Indicates if the merchant is opting out or in for rate processing and that the default currency conversion rates are used.

Valid values: Y – Merchant is opting out of the processing

for custom IB rates. N – Default value. Merchant is opting in for

the processing of custom IB rate. Note: If the Opt-out Indicator = “Y”, then all of the subsequent fields in the record are populated with spaces.

1 A Rate Handling Indicator

Indicator to allow the merchant to determine the processing of the Rate ID. If there is an issue with the Rate ID, the transaction can either be rejected or it can use a default rate ID for Deposit processing.

Valid values: D = Default Rate ID is used if the Rate ID cannot be determined. R = Reject the transaction if the Rate ID cannot be determined.

Notes: If the Opt-out Indicator field = Y, this field can be blank. If the Opt-out Indicator field = N", this field is mandatory.

If the Opt-out Indicator field is Y, but an invalid value is sent in the Rate Handling Indicator field, the transaction rejects with Response Reason Code 225 (Invalid Field Data) and has a Rate Status of “010.”



RECORD LAYOUTS FOR ONLINE SPECIFICATION, (Continued)

ACCESS FX Cross Currency Format Indicator (FX), (Continued)


37 A Rate Identifier Rate identifier is used to indicate the rate that is being used for the transaction.


20 N Exchange Rate Exchange Rate is populated from the Rate field in the Merchant Rate File and is used for the cross currency conversion. Include the decimal as it is sent.

Left justified/space filled

Note: This should be the exact value from the rate file for the selected rate.

3 N Presentment Currency

Presentment Currency involved in the transaction.

Right justified/zero filled.

Example: ISO Numeric value for Euro is 978

3 N Settlement Currency

Settlement Currency involved for Settlement.



Note: See Appendix AR: ACCESS FX Cross Currency for additional information on populating this Format Indicator.

Sample 8 9 0 1 2 3 4 5 5678901234567890123456789012345678901234567890123456789012345678901 FXNDa12345678-1a2b-3cde-a123-45b6c7d89e001.23456789 840978



Goods Sold Format Indicator (GS)


2 A Format Indicator "GS" Constant – Goods sold information. Specifies this record as an additional processing format of the Merchant Services standard format.

4 A Goods Sold Goods sold product type. Valid values:

1000 – Gift Card “ “ – Blank

Note: This Format Indicator is used only for American Express authorizations.

Sample 8 9 567890 GS1000



Formatted Ship To Name Format Indicator (HN)


2 A Format Indicator "HN" Constant – Formatted ship to name information. Specifies this record as an additional processing format of the Merchant Services standard format.

15 A First Name Ship to first name.


30 A Last Name Ship to last name.


Notes: This Format Indicator overrides the Name Text field populated in the Ship to Address Format Indicator (AS).


Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901 HNMARGO WILD



Healthcare IIAS Format Indicator (II)


2 A Format Indicator Type "II" Constant – Healthcare IIAS information. Specifies this record as an additional processing format of the Merchant Services standard format.

12 N QHP Amount Total amount of qualified healthcare purchase.


Note: This field cannot be all blanks or zeros, or the transaction rejects with Response Reason Code 265 (Missing QHP Amount).

12 N RX Amount Total amount of qualified RX purchase. (Optional)


12 N Vision Amount Total amount of qualified vision/optical purchase. (Optional)


12 N Clinic/Other Amount Total amount of qualified clinic/other purchase. (Optional)


12 N Dental Amount Total amount of qualified dental purchase. (Optional)


1 A IIAS Flag Indicates the merchant has implemented an Inventory Information Approval System (IIAS) and used it to get the QHP Amount for this transaction.

Valid value: Y – Yes




Healthcare IIAS Format Indicator (II), (Continued)

Notes: If QHP Amount is greater than the Amount in the Online Processing Detail Record, the transaction rejects with Response Reason Code 266 (Invalid QHP Amount).

If the total of the RX Amount, Vision Amount, Clinic/Other Amount and Dental Amount exceeds the QHP Amount, the transaction rejects with Response Reason Code 266 (Invalid QHP Amount).

This Format Indicator can only be sent if the merchant is registered at Merchant Services for IIAS participation, or the transaction rejects with Response Reason Code 267 (Merchant Not IIAS Enabled).

This Format Indicator must be sent when Action Code = AU or PA and the account number BIN is a Healthcare BIN and the MCC for the transaction is not exempt from participating in IIAS, or the transaction rejects with Response Reason Code 265 (Missing QHP Amount).

Sample 8 9 0 1 2 3 4 567890123456789012345678901234567890123456789012345678901234567 II000000002500000000002500 Y



JCB Authentication Format Indicator (JA)


2 A Format Indicator "JA" Constant – JCB authentication information.

Specifies this record as an additional processing format of the Merchant Services standard format.

40 A American Express Authentication Verification Value (AEVV) (Block A)

Unique transaction cryptogram generated by the merchant’s digital wallet provider.


Notes: The cryptogram could be in one of two sizes:

• 28-byte Base 64 or 20-byte binary (hexadecimal ASCII character) format

• 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format

When sending 28-byte Base 64 or 20-byte binary (hexadecimal ASCII character) format, this field (Block A) is populated with the value. The XID field (Block B) should be blank filled.

When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in this field and the second block of data must be populated in the Transaction ID (XID) field. Must be sent in a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).




JCB Authentication Format Indicator (JA), (Continued)


American Express Authentication Verification Value (AEVV) (Block A), (Continued)

Notes, (Continued) :

For original authorizations, this field is required. For subsequent authorizations (i.e., split/delayed shipments), this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For recurring authorizations,Transaction Type must equal 2 and this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

40 A Transaction ID (XID) (Block B)






When sending 28-byte Base 64 or 20-byte binary (hexadecimal ASCII character) format, the American Express Authentication Verification Value (AEVV) (Block A) field is populated with the value. This field should be blank filled.

When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in the American Express Authentication Verification Value (AEVV) (Block A) field and the second block of data must be populated in this field.






Transaction ID (XID) (Block B), (Continued)

Notes, (Continued):

Must be sent in a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For original authorizations, this field is required and the Transaction Type must be 5 or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For subsequent authorizations (i.e., split/delayed shipments), this field must be blank when Transaction Type = 5 and the American Express Authentication Verification Value (AEVV) (Block A) populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For recurring authorizations, this field must be blank when Transaction Type = 2 or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).





Notes: This Format Indicator is for Canadian merchants only. Transactions are processed on the American Express network and use the same fields as American Express. When using this Format Indicator the Transaction Type field must be populated with a “2” or a “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The cryptogram is either:


or • 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format


When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in this field and the second block of data must be populated in the Transaction ID (XID) field. If the fields are not populated in either a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value, the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

See Appendix AM: Consumer Digital Payment Token for product information.

Sample for JCB Authorization 8 9 0 1 2 567890123456789012345678901234567890123456 JASUBSEQUENT000000000000000000



Fraud Scoring 1 Format Indicator (KT01)


4 A Format Indicator "KT01" Constant – Fraud scoring information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Return Rules Triggered Indicates whether the Agent Web Console (AWC) triggered rules are returned.

Valid values: Y – Triggered rules are returned N – Triggered rules are not returned " " – Triggered rules are not returned

Notes: When this field = Y, the Rules Triggered Reply Format Indicator (KR) is returned.

When this field = N or blank, the Rules Triggered Reply Format Indicator (KR) is not returned.

6 A Safetech Merchant ID The fraud scoring ID for the merchant.


Notes: This is NOT the Transaction Division of the merchant.

This field and Kaptcha Session ID values are related to the Kaptcha data.

If this value is not sent, Merchant Services does not reject the transaction. However, the transactions does not receive a fraud score.

32 A Kaptcha Session ID The merchant generated session ID. (Optional)


Notes: This field and Safetech Merchant ID values are related to the Kaptcha data.

This value should be unique for at least 30 days or the Safetech Risk Score may not be accurate.




Fraud Scoring 1 Format Indicator (KT01), (Continued)


Kaptcha Session ID, (Continued)

Notes, (Continued):

If this field is not populated, the Merchant’s Order Number value (located on the Online Processing Detail Record) is used.

This can only use upper and lower case alpha (A-Z, a-z) and numeric (0-9).

8 A Website Short Name Short name for the merchant’s website.


Notes: This value is used for fraud score rules.

The Website Short Name can be defaulted at the Transaction Division level. To override the Transaction Division default, a Website Short Name must be added to the AWC before sending it on the transaction, or the transaction receives Fraud Status Code K323 (The Website ID is invalid).

If this field and the Transaction Division are not populated, the default fraud score rules are applied.

Notes: This Format Indicator or Fraud Scoring 2 Format Indicator (KT02) is required when a merchant wishes to participate in fraud scoring.

This Format Indicator or Fraud Scoring 2 Format Indicator (KT02) is required when Action Code = FA or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If both Format Indicators are sent, the transaction rejects with Response Reason Code 225 (Invalid Field Data).


Sample 8 9 0 1 2 3 567890123456789012345678901234567890123456789012345 KT01 1234560FEAF32302CC95C3683ECA543F8D7577MERCHANT



Fraud Scoring 2 Format Indicator (KT02)


4 A Format Indicator "KT02" Constant – Fraud scoring information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Return Rules Triggered Indicates whether the Agent Web Console (AWC) triggered rules are returned.

Valid values: Y – Triggered rules are returned N – Triggered rules are not returned " " – Triggered rules are not returned

Notes: When this field = Y, the Rules Triggered Reply Format Indicator (KR) is returned.

When this field = N or blank, the Rules Triggered Reply Format Indicator (KR) is not returned.

6 A Safetech Merchant ID The fraud scoring ID for the merchant.

Notes: This is NOT the Transaction Division of the merchant.

This field and Kaptcha Session ID values are related to the Kaptcha data.

If this value is not sent, Merchant Services does not reject the transaction. However, the transactions does not receive a fraud score.

32 A Kaptcha Session ID The merchant generated session ID. (Optional)


Notes: This field and Safetech Merchant ID values are related to the Kaptcha data.

This value should be unique for at least 30 days or the Safetech Risk Score may not be accurate.






Kaptcha Session ID, (Continued)

Notes, (Continued):

If this field is not populated, the Merchant’s Order Number value (located on the Online Processing Detail Record) is used.

This can only use upper and lower case alpha (A-Z, a-z) and numeric (0-9).

8 A Website Short Name Short name for the merchant’s website.


Notes: This value is used for fraud score rules.

The Website Short Name can be defaulted at the Transaction Division level. To override the Transaction Division default, a Website Short Name must be added to the AWC before sending it on the transaction, or the transaction receives Fraud Status Code K323 (The Website ID is invalid).

If this field and the Transaction Division are not populated, the default fraud score rules are applied.

12 N Cash Value of Fencible Items

The cash value of any fencible items in the order. (Optional)


10 A Customer Date of Birth Customer date of birth. (Optional)

YYYY-MM-DD format

Example: 1970-07-04

1 A Customer Gender Gender of the customer. (Optional)

Valid values: F – Female M – Male “ “ – Blank






32 A Customer Driver’s License Number

U.S. Driver’s license number. (Optional)


32 A Customer ID A merchant generated ID for a specific customer. (Optional)


10 N Customer ID Creation Time

Time when the Customer ID was created. (Optional)

UNIX Epoc format Notes: This Format Indicator or Fraud Scoring 1 Format Indicator (KT01) is required when a merchant wishes to participate in fraud scoring.

This Format Indicator or Fraud Scoring 1 Format Indicator (KT01) is required when Action Code = FA or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If both Format Indicators are sent, the transaction rejects with Response Reason Code 225 (Invalid Field Data).


Sample

8 9 0 1 2 3 4 5 6 7 56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 KT02 1234560FEAF32302CC95C3683ECA543F8D7577MERCHANT 1950-06-15

8 9 0 1 2 3 01234567890123456789012345678901234567890123456789012



User Defined and Shopping Cart Format Indicator (KTT1)


3 A Format Indicator "KTT" Constant – Fraud scoring information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 N Version Number Indicates the version number of the format indicator. This number initially begins with “1”.

4 N Data Length Indicates the number of positions submitted for the following field.

Valid values: 0001-0999

Variable 001-999

A Data String A variable data string.

Left justified/blank filled, cannot be all blanks

Notes: This field can be populated with user-defined (UDF) AWC rule values, shopping cart data, or both.

There can be multiple strings sent in one record.

Each item (UDF data OR shopping cart data) must be terminated with the ‘|’ (pipe) character, and the ‘|’ (pipe) character cannot be used as part of the data itself. The ‘|’ (pipe) character MUST be the last character in the Format Indicator.

If the format of either the UDF or shopping cart data string is invalid, the transaction is not sent to the Safetech fraud scoring system. Fraud Status Code X008 (Invalid Shopping Cart Data. RIS Inquiry Not Attempted) or X009 (Invalid User-Defined Field Data. RIS Inquiry Not Attempted) may be returned.




User Defined and Shopping Cart Format Indicator (KTT1), (Continued)


Data String, (Continued)

Notes, (Continued):

To enable merchants to embed ampersands, equal signs, and pipe characters within the data itself, the data supplied must be URI (Uniform Resource Identifier) encoded. The following characters are the only ones that should be URI encoded. URI Encoded Characters

& - %26 | - %7C = - %3D

User-Defined String A UDF string consists of pre-defined labels and actual values. These labels must be previously defined by the merchant in the Agent Web Console (AWC) on the Decision Management Console (DMC) tab. Ud=x&| format where:

U = Constant (Uppercase U) d = Previously defined AWC label = = Constant (Equal sign) x = Rule value for this transaction & = Constant (Ampersand) | = Constant (Pipe)

Example: UPROMOCODE=40&|

Notes: If the value of "d" is not defined in the AWC, Fraud Status Code = K399 (The label either doesn’t exist or was associated with the wrong data type) is returned.

If more than one value of “d” is sent, only the last value sent appears in the AWC.







Notes, (Continued): Values for “d” and “x” cannot be blank.

If any of the previously defined AWC labels (“d” value) are related to an amount, the value should be two decimal implied.

If any of the previously defined AWC labels (“d” value) are related to a date, the format should be yyyy-mm-dd.

If any of the previously defined AWC labels (“d” value) are related to a time, the format should be hh:mm:ss where “hh” is 24 hours.

If any of the previously defined AWC labels (“d” value) are related to a date and a time, the format should be yyyy-mm-dd hh:mm:ss.

The constant (U) and the delimiters (&, =, |) must NOT be URI encoded.

Shopping Cart Data String A Shopping Cart data string is the line item detail of a transaction. Each line item must contain five sub-elements.

The sub-elements are defined as: T = Type I = Item D = Description Q = Quantity (must be numeric) P = Price (must be numeric)

Note: This sub-element is two decimal implied.







Notes, (Continued): The string format is:

T=a&I=b&D=c&Q=d&P=e&| where:

T, I, D, Q, P Constant (Uppercase) – Identifies the sub-element.

= Constant (Equals) a, b, c, d, e Active value of the sub-

element. & Constant (Ampersand) –

Identifies the end of the specified sub-element.

| Constant (Pipe) – Identifies the end of the shopping cart data string.

Each string must contain all 5 sub-elements.

The constants (T, I, D, Q, P) and the delimiters (&, =, and |) must NOT be URI encoded.

Example: T=TV&I=SKU123&D=42 Plasma&Q=1&P=70000&|





Notes: This Format Indicator should be sent when a merchant wishes to submit order item data for fraud scoring. See Appendix AE: Safetech Fraud Tools for additional information.

Samples:

User-Defined String 8 9 0 56789012345678901234567 KTT10015UPROMOCODE=40&|

Shopping Cart Data String 8 9 0 1 2 3 5678901234567890123456789012345678901234567890 KTT10038T=TV&I=SKU123&D=42Plasma&Q=1&P=70000&|

Both User-Defined String and Shopping Cart Data String 8 9 0 1 2 3 4 5678901234567890123456789012345678901234567890123456789012345 KTT10053UPROMOCODE=40&|T=TV&I=SKU123&D=42Plasma&Q=1&P=70000&|



Lodging Format Indicator (LG)


2 A Format Indicator "LG" Constant – Lodging information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 N Duration Number of anticipated days for hotel stay.


Sample 8 5678 LG01



Formatted Bill to Name Format Indicator (LN)


2 A Format Indicator "LN" Constant – Formatted bill to name information. Specifies this record as an additional processing format of the Merchant Services standard format.

15 A First Name Accountholder’s first name.


30 A Last Name Accountholder’s last name.


Notes: This Format Indicator overrides the Name Text field populated in the Bill to Address Format Indicator (AB).


Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901 LNJOHN SMITH



MasterCard Authentication Format Indicator (MA)


2 A Format Indicator "MA" Constant – MasterCard SecureCode information.


32 A Accountholder Authentication Value (AAV)

MasterCard SecureCode Unique transaction token generated by the Issuer and presented to the merchant each time an accountholder conducts an electronic transaction using MasterCard SecureCode.

A MasterCard assigned static AAV may also be provided for eligible merchants. This is the same format used by MasterCard when returning the AAV data to the merchant during the authentication step.

Left justified/blank filled Consumer Digital Payment Token Unique transaction cryptogram generated by the merchant’s digital wallet provider.



DO NOT MANIPULATE this value in any way. For original authorizations, this field is required and must be a valid Base 64 value.

For subsequent authorizations (i.e., split/delayed shipments), this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).





MasterCard Authentication Format Indicator (MA), (Continued)

Notes: This Format Indicator can be sent when MOP = IM, MC, or MR.

MasterCard SecureCode This Format Indicator should be sent for e-commerce transactions for International Maestro cards. See the International Maestro User Guide for details.

Transaction division level flag must be set in order to process MasterCard Authentication transactions, or the transaction rejects with Response Reason Code 246 (Merchant Not MasterCard SecureCode Enabled).

When using this Format Indicator, the Transaction Type field should be populated with the ECI value that the merchant received back from the merchant plug-in software. However, if using static AAV, see the MARP and MRPP sections below.

MARP When using this Format Indicator, if a European merchant is using International Maestro (IM) or MasterCard (MC), is participating in the Maestro Advanced Registration Program (MARP), and chooses to use static AAV, the Transaction Type field should be populated with a "5."

MRPP

When using this Format Indicator, if a European merchant is using International Maestro (IM), is participating in Maestro Recurring Payment Program (MRPP), the AAV provided must be a static AAV, and the Transaction Type must = 2, or the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

See Appendix I: MasterCard SecureCode for product information.

Consumer Digital Payment Token When using this Format Indicator the Transaction Type field must be populated with a “2” or a “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).


Sample for MasterCard SecureCode 8 9 0 1 5678901234567890123456789012345678 MAgodlOEAxmL4wH7108KtV0QkAQAS=Rx1o



Mobile POS Device Information Format Indicator (MB)


2 A Format Indicator "MB" Constant – Mobile POS device information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Device Type Indicates the transaction is being conducted via a mobile POS device. Valid values:

1 – Mobile POS Device " " – Blank

Note: Used by ChaseNet, Discover, Discover Diners, JCB, MasterCard, and Visa when Action Code = AU and AR.

Sample 8 567 MB1



Merchant Descriptor Format Indicator (MD)


2 A Format Indicator "MD" Constant – Merchant Descriptor information. Specifies this record as an additional processing format of the Merchant Services standard format.

22 A Soft Merchant Name and/or Item Description

Descriptor that appears on the accountholder's statement.


Notes: If this field is blank, the transaction division default is used.

This field is only sent to the card brands when the transaction division flag is enabled. Otherwise, the transaction division default is used.

There are three possible formats:

Option Description 1 3-byte company identifier "*"

18-byte descriptor

2 7-byte company identifier "*" 14-byte descriptor

3 12-byte company identifier "*" 9-byte descriptor

The description in the merchant name field should be what is most recognizable to the accountholder. It should consist of the company name and/or trade name combined with some type of description of the product or service that was purchased.

DO NOT USE the following punctuation: caret (^), backslash (\), open bracket ([), closed bracket (]), tilde (~), or accent key (`).

4 A Reserved Blanks




Merchant Descriptor Format Indicator (MD), (Continued)


13 A Soft Merchant City/Customer Service Phone Number

City or customer service phone number that appears on the accountholder's statement.


Notes: If this field is blank, the transaction division default is used.

Recommended formats by merchant channel:

Card Present

City of store location formatted as:

AAAAAAAAAAAAA

Card Not Present

• Customer Service phone number formatted as:

NNN-NNN-NNNN (U.S. and Canada) NNN-AAAAAAA (U.S. and Canada) NNN-NNNNNNN (U.S. and Canada)

Notes: ChaseNet (U.S. only), International Maestro, MasterCard, and Visa international transactions may include the above formats or any 13 byte format.

All other International Methods of Payment must follow one of the above formats.

• URL (Non-e-Commerce) transactions sent with URL do not qualify for the best interchange rate.

• Email address

For International Maestro and MasterCard MOTO (Transaction Type 1) and Recurring (Transaction Type 2), this field should be populated when the City/Phone and Contact Phone Number fields at the transaction division level is not a customer service phone number. For international transactions, DO NOT USE the following punctuation: caret (^), backslash (\), open bracket ([), closed bracket (]), tilde (~), or accent key (`).




Merchant Descriptor Format Indicator (MD), (Continued)

Notes: Prior Risk Department approval is required. Please contact your Merchant Services Representative.

Subject to Issuer discretion whether this descriptor is displayed on the accountholder’s statement.

Telecommunication transactions ignore Soft Merchant Descriptors.

Please see Appendix T: Soft Merchant Information and Merchant Descriptor for additional information on populating this record.

Sample 8 9 0 1 2 56789012345678901234567890123456789012345 MDXYZ*PYMNT 1 of 3



Merchant Echo Format Indicator (ME)


2 A Format Indicator "ME" Constant – Merchant echo information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 N Length Indicator Indicates the number of positions submitted for the following field:


Variable 1-99

A Merchant Echo Field Value submitted by merchant that is returned in the Merchant Echo Reply Format Indicator (ME).

Sample 8 9 0 1 56789012345678901234567890 ME22MERCHANT SUPPLIED INFO



MoneyPak Format Indicator (MP)


2 A Format Indicator

"MP" Constant – MoneyPak information. Specifies this record as an additional processing format of the Merchant Services standard format.

20 A Original Transaction ID

Original transaction ID received at purchase authorization time. (Optional)


Notes: When Action Code = BI or PA, this field should be blank.

When Action Code = RA, this field must be populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Populate with the Original Transaction ID returned on the original purchase authorization (Action Code = PA).

25 A Confirmation ID Confirmation ID returned at time of Purchase Authorization. (Optional)


Notes: When Action Code = BI or PA, this field should be blank.

When Action Code = RA, this field must be populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Populate with the Confirmation ID returned on the original purchase authorization (Action Code = PA).

20 N MoneyPak Account Number

20-byte MoneyPak Account Number. (Optional)

Notes: This field value must be 20 bytes in length, or the transaction rejects with Response Reason Code 201 (Invalid Account Number).

If this field is populated, the Account Number field in the Online Processing Detail Record must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 1 2 3 4 5 5678901234567890123456789012345678901234567890123456789012345678901 MP 98765432100123456789



Message Type Records Format Indicator (MT)


2 A Format Indicator "MT" Constant – Message Type Records information. Specifies this record as an additional processing format of the Merchant Services standard format.

4 A Message Type Indicates the message type to be used for the message type records.

Refer to the Message Types Grid table in Appendix AQ: Cardholder and Merchant Initiated Transactions for additional information.

1 A Stored Credential Flag Indicates that the cardholder’s credentials are on-file with the merchant.

Valid values: Y – The cardholder’s credentials are on-file with the merchant N – The cardholder’s credentials are not on-file with the merchant “ “ – Blank

Note: If this field is sent, but does not contain one of the above values, the transaction rejects with Response Reason Code 279 (Invalid MT Record Format).

15 A Submitted Transaction ID

The Submitted Transaction ID (TXID) returned to the merchant from a previous authorization request in a series of transactions. (Optional)


Notes: Refer to Appendix AQ: Cardholder Initiated/Merchant Initiated Transactions for specific rules by message type. If this field is populated or omitted for certain message types, the transaction rejects with Response Reason Code 279 (Invalid MT Record Format).




Message Type Records Format Indicator (MT), (Continued)


15 A Response Transaction ID

Response Transaction ID (TXID) – this is returned to the merchant and is output-only.


Note: Visa’s preference is that the merchant store the TXID from the initial CIT (original TXID) for future MIT purchases. Some CIT/MIT categories (i.e., hotel or car rental incremental) require use of the original TXID for support.

12 A Filler Reserved (for future use)

Notes: If a Message Type Record is sent, but is not formatted properly, the transaction rejects with Response Reason Code 279 (Invalid MT Record Format).

Message Type Records are valid for ChaseNet and Visa transactions only.

Message Type Examples Sample for MUSE 8 9 0 1 2 567890123456789012345678901234567890123456789 MTMUSEY123456789876543



Miscellaneous 1 Format Indicator (M1)


2 A Format Indicator "M1" Constant – Miscellaneous 1 information. Specifies this record as an additional processing format of the Merchant Services standard format.

11 A Dealer Number Merchant internal number that identifies a particular store location.


Sample 8 9 5678901234567 M112345678901



Order Information Format Indicator (OI)


2 A Format Indicator "OI" Constant – Order information. Specifies this record as an additional processing format of the Merchant Services standard format.

3 A Product Delivery Type Indicator

Delivery type of product. (Optional)

Valid values: CNC – Cash & Carry (BML/BML PL) DIG – Digital Goods (BML/BML

PL/ChaseNet/Visa) PHY – Physical Delivery Required

(BML/BML PL/ChaseNet/Visa) SVC – Service (BML/BML PL) TBD – To Be Determined (BML/BML PL)

2 A Shipping Carrier Shipment carrier for an item. (Optional)

Valid values: DH – DHL FE – Federal Express GH – Greyhound OH – Other PL – Purolator PS – USPS UP – United Parcel Service




Order Information Format Indicator (OI), (Continued)


1 A Shipping Method Method of shipment for an item. (Optional)

Valid values: C – Lowest Cost D – Carried Designated by Customer E – Electronic Delivery * G – Ground * I – International M – Military N – Next Day/Overnight * O – Other/Standard P – Store Pickup * S – Same Day * T – Two Day Service * W – Three Day Service *

Notes: For American Express, the valid values have been marked with ‘ * ’. If an invalid value is sent for American Express transactions, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This field should be sent when Safetech fraud scoring is requested.

6 N Order Date Date of order. (Optional)

YYMMDD format

6 N Order Time Time of order. (Optional)

HHMMSS format Note: This Format Indicator is recommended when Safetech fraud scoring is requested.

Sample 8 9 0 56789012345678901234 OIPHYFEN030930153000



Order Information 2 Format Indicator – PINless Debit Only (O2)


2 A Format Indicator "O2" Constant – Order information 2. Specifies this record as an additional processing format of the Merchant Services standard format.

25 A Biller Reference Number

Reference number the biller (merchant) uses on his system to identify the customer.


Note: This Format Indicator must be sent when MOP = DP or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Sample 8 9 0 1 567890123456789012345678901 O2BILLREFNUM123



Order Information 3 Format Indicator (O3)


2 A Format Indicator "O3" Constant – Order information 3. Specifies this record as an additional processing format of the Merchant Services standard format.

15 A SKU Merchant’s product SKU number.


Sample 8 9 0 56789012345678901 O3SKU NUMBER





2 A Format Indicator "O5" Constant – Order Information 5. Specifies this record as an additional processing format of the Merchant Services standard format.

30 A T&C ID Number The Terms & Conditions identification number agreed to by the customer.


30 A T&C Version Number The Terms & Conditions version number agreed to by the customer.


6 N T&C Date Date customer accepted the Terms & Conditions.

YYMMDD format

6 N T&C Time Time the customer accepted the Terms & Conditions.

HHMMSS format (GMT) Note: This Format Indicator must be sent when MOP = C9 and Action Code = ET or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Sample 8 9 0 1 2 3 4 5 56789012345678901234567890123456789012345678901234567890123456789012345678 O51234567890 A123456789 100727091543




Length

Data Type

Field Name

Comments

2 A Format Indicator "O6" Constant – Order Information 6. Specifies this record as an additional processing format of the Merchant Services standard format.

4 A Product Code Code assigned to the rewards program. (Optional)


Note: This field must be populated when MOP = C9 and Action Code = AU or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

12 N Rewards Transaction Amount

The number of rewards for this transaction. (Optional)


5 A Rewards Currency Unit of measure of the rewards being redeemed. (Optional) Left justified/blank filled Valid values:

USD – Cash WPTS – Points MLS – Miles

Note: This field should be populated with the same value as returned when Action Code = BI.

10 N Conversion Rate Value used to convert U.S. Dollars to rewards. (Optional)


Note: This field must be populated when MOP = C9 and Action Code = AU or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

12 A Shop with Points Trace Number

Shop with Points trace number from approved, original, authorized transaction. (Optional)


Note: This field should be populated when MOP = C9 and Action Code = AR or AU for best transaction matching.




Order Information 6 Format Indicator (O6), (Continued)

Notes: This Format Indicator should be sent when MOP = C9 and Action Code = AR or AU.

This Format Indicator must be sent when MOP = C9 and Action Code = AU or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Rewards Transaction Amount should be rounded to the nearest whole number. When Action Code = AU, round down.

Examples: $25.00 (Online Processing Detail Record Amount) X 125 (Conversion Rate) = 3125.00 (Rewards Transaction Amount)

$25.98 (Online Processing Detail Record Amount) X 125 (Conversion Rate) = 3247.50, rounded to the nearest whole number is 3247.00 (Rewards Transaction Amount)

The sample indicates Action Code = AU: Sample 8 9 0 1 2 567890123456789012345678901234567890123456789 O60441000000312500WPTS 0000000125





2 A Format Indicator "O7" Constant – Transaction surcharge information. Specifies this record as an additional processing format of the Merchant Services standard format.

8 N Surcharge Amount Amount of the surcharge for the transaction. Two decimal implied/right justified/zero filled

Notes: This is a notification field only. The surcharge amount should be included in the Amount field located on the Online Processing Detail Record. This format indicator is only used for ChaseNet – Credit, ChaseNet - Signature Debit/Prepaid, Discover, Discover Diners, JCB, MasterCard, and Visa. The surcharge amount can be up to 4% of the sale amount for MasterCard and Visa. Merchant Services does not edit these rules; the card brands do. Sample 8 9 5678901234 O700000200



Prior Authorization and Reversal Reason Format Indicator (P4)


2 A Format Indicator "P4" Constant – Reversal Reason Code. Specifies this record as an additional processing format of the Merchant Services standard format.

6 N Response Date Date of approved, original, authorized transaction. (Optional)

YYMMDD format

Notes: When MOP = C9 and Action Code = AR, this field is optional, however, it should be sent for best transaction matching.

For all other MOPs, this field must be current or prior date when Action Code = AR or the transaction rejects with Response Reason Code 262 (Authorization Code/Response Date Invalid).

6 A Authorization Code Authorization code of the approved, original, authorized transaction. (Optional)



For all other MOPs, this field cannot be blank when Action Code = AR, or the transaction rejects with Response Reason Code 262 (Authorization Code/Response Date Invalid).

8 A Debit Trace Number Debit trace number from approved, original, pre-authorized transaction. (Optional)


Notes: This field should be blank when MOP = C9.

When MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR, this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data).




Prior Authorization and Reversal Reason Format Indicator (P4), (Continued)


1 A Reversal Reason Code Reversal Reason Code used for a suspected fraudulent transaction. Valid values:

F - Auth Reversal Suspected Fraud “ “ – Blank

Notes: Systematic declines of card not present transactions from a specific issuer, a specific product, or from a specific issuing country do not and will not qualify as a good faith belief there is a fraud risk. A no match response on an AVS or Card Security Value request should not be the only cause to reverse a transaction due to suspected fraud. Only used by International Maestro, MasterCard, and MasterCard Canadian Domestic Restricted Debit.

Notes: This Format Indicator or the Prior Authorization Format Indicator (PA) must be sent when Action Code = AR and MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI or VR, or the transaction rejects with Response Reason Code 227 (Missing Companion Data). This Format Indicator or the Prior Authorization Format Indicator (PA) should be sent when Action Code = AR and MOP = C9.

When MOP = any PINless Debit MOP, this Format Indicator can only be sent when Action Code = DR or PR or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

See Appendix F: Authorization Reversals for system requirements.

See Appendix L: Debit Processing for system requirements.


Sample 8 9 0 56789012345678901234567 P4070427123456 F



Prior Authorization Format Indicator (PA)


2 A Format Indicator "PA" Constant – Prior authorization information. Specifies this record as an additional processing format of the Merchant Services standard format.

6 N Response Date Date of approved, original, authorized transaction. (Optional)

YYMMDD format


For all other MOPs, this field must be current or prior date when Action Code = AR or the transaction rejects with Response Reason Code 262 (Authorization Code/Response Date Invalid).

6 A Authorization Code Authorization code of the approved, original, authorized transaction. (Optional)


Notes: This field must be populated when MOP= EB or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

When MOP = C9 and Action Code = AR, this field is optional, however, it should be sent for best transaction matching.

For all other MOPs, this field cannot be blank when Action Code = AR, or the transaction rejects with Response Reason Code 262 (Authorization Code/Response Date Invalid).

8 A Debit Trace Number Debit trace number from approved, original, pre-authorized transaction. (Optional)


Notes: This field should be blank when MOP = EB or C9.

When MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR, this field must be blank or the transaction rejects with Response Reason Code 225 (Invalid Field Data).




Prior Authorization Format Indicator (PA), (Continued)

Notes: This Format Indicator or the Prior Authorization and Reversal Reason Format Indicator (P4) must be sent when Action Code = AR and MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI or VR, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator must be sent when Action Code = PC and MOP = EB or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator or the Prior Authorization and Reversal Reason Format Indicator (P4) should be sent when Action Code = AR and MOP = C9.

When MOP = any PINless Debit MOP, this Format Indicator can only be sent when Action Code = DR or PR or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

See Appendix F: Authorization Reversals for system requirements.

See Appendix L: Debit Processing for system requirements.


Sample 8 9 0 5678901234567890123456 PA070427123456



Partial Authorization Format Indicator (PB)


2 A Format Indicator "PB" Constant – Partial authorization information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Partial Redemption Indicator Flag

Determines approval functionality for pre-paid/gift card authorizations.

Valid values for American Express and JCB: Y – Transaction is not declined if authorization

amount is greater than the current balance.

N – Transaction is declined if authorization amount is greater than the current balance.

Valid values for Discover and Discover Diners: Y – The sale amount can be partially approved

but the cash back amount cannot be partially approved.

N – Merchant does not support partial authorization. Partial authorization not allowed for both sale amount and cash back amount.

B – Both sale amount and cash back may be partially approved. The sale amount must be fully approved before the cash back amount can be partially approved.

C – The sale amount must be fully approved before the cash back amount may be partially approved.

X – Merchant may support partial authorizations, but the sale amount must be fully approved before the cash back amount can be approved. Neither the sale amount nor the cash back amount can be partially approved.

Valid values for ChaseNet, Debit, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit:

Y – Attempt a partial authorization if allowed for the account.

N – Do not attempt a partial authorization. Continued on next page



Partial Authorization Format Indicator (PB), (Continued)


Partial Redemption Indicator Flag, (Continued)

Valid values for PIN-Based Debit: Y – The sale amount can be partially

approved but the cash back amount cannot be partially approved.

N – Merchant does not support partial authorization. Partial authorization not allowed for both sale amount and cash back amount.

Valid values for MoneyPak:

Y – Attempt a partial authorization. N – Do not attempt a partial authorization.

Notes: See Appendix G: Partial Authorization for product information.

American Express and JCB: Sending the Partial Redemption Indicator Flag does not override the transaction division default.

However, if the transaction division default is set to support or not support partial authorization, then the Partial Redemption Indicator Flag is used for processing the transaction.

Discover and Discover Diners: Sending the Partial Redemption Indicator Flag overrides the transaction division default.

ChaseNet, Debit, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit: Sending the Partial Redemption Indicator Flag overrides the transaction division default.

If the Action Code is not partial authorization-capable, the Partial Redemption Indicator Flag is ignored.

MoneyPak: Sending the Partial Redemption Indicator Flag overrides the transaction division default.

Sample 8 567 PBY



Payment Device Format Indicator (PD)


2 A Format Indicator "PD" Constant – Mobile POS device information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Payment Device Indicates the type of mobile POS device. Valid values:

00 – Card 01 – Mobile Phone or Smartphone with

Mobile Network Operator (MNO) controlled removable secure element (SIM or UICC) personalized for use with a mobile phone or smartphone

02 – Key Fob 03 – Watch 04 – Mobile Tag 05 – Wristband 06 – Mobile Phone Case or Sleeve 07 – Mobile phone or smartphone with

a fixed (non-removable) secure element controlled by the MNO, for example, code division multiple access (CDMA)

08 – Mobile Phone or Smartphone with Removable secure element not controlled by the MNO, for example, memory card personalized for used with a mobile phone or smartphone

09 – Mobile Phone or smartphone with a fixed (non-removable) secure element not controlled by the MNO

10 – Tablet or e-Reader with an MNO controlled removable secure element (SIM or UICC) personalized for used with a tablet or e-book




Payment Device Format Indicator (PD), (Continued)


Payment Device, (Continued

Valid values, (Continued):

11 – Tablet or e-book with a fixed (non-removable) secure element controlled by the MNO

12 – Removable secure element not controlled by the MNO, for example, memory card personalized for use with a tablet or e-book

13 – Tablet or e-book with fixed (non-removable) secure element not controlled by the MNO

14 – Mobile Phone or Smartphone with a payment application running in a host processor.

15 – Tablet or e-Reader with a payment application running in a host processor.

16- – Mobile Phone or Smartphone with payment application running in the TEE of a host processor

17 – Tablet or E-Book with a payment application running in the TEE of a host processor.

18 – Watch with a payment application running in the TEE of a host processor.

19 – Watch with a payment application running in a host processor.

20-99

– Reserved for Future Use

3 A Reserved Blanks

Sample 8 9 5678901 PD01



Personal Information Format Indicator (PI)


2 A Format Indicator "PI" Constant – Customer personal information. Specifies this record as an additional processing format of the Merchant Services standard format.

8 N Customer Date of Birth Customer date of birth. (Optional)

YYYYMMDD format

9 N Customer Social Security Number

Customer social security number. (Optional)

Note: For Bill Me Later and Bill Me Later Private Label, when sending only the last four digits, the first five bytes must be zero filled. Example: 000001234

3 A Currency Type of Gross Household Annual Income

Currency type of gross household annual income. (Optional)

Valid values: 036 – Australian Dollar 826 – British Pound 124 – Canadian Dollar 208 – Danish Krone 978 – Euro 344 – Hong Kong Dollar 392 – Japanese Yen 554 – New Zealand Dollar 578 – Norwegian Krone 702 – Singapore Dollar 710 – South African Rand 752 – Swedish Krona 756 – Swiss Franc 840 – U.S. Dollar

10 N Gross Household Annual Income

Gross household annual income. (Optional)





Personal Information Format Indicator (PI), (Continued)


1 A Customer Residence Status

Status of customer residence. (Optional)

Valid values: O – Own R – Rent X – Other

2 N Customer Years at Residence

Number of years at current residence. (Optional)

Left justified/blank filled Note: Round up to nearest year. Example: 5 months = 1

2 N Customer Years at Employer

Number of years with current employer. (Optional)


Note: Round up to nearest year. Example: 6 months = 1

1 A Customer Checking Account

Customer checking account indicator. (Optional)

Valid values: Y – Customer has checking account. N – Customer does not have checking

account.

1 A Customer Savings Account

Customer savings account indicator. (Optional)

Valid values: Y – Customer has savings account. N – Customer does not have savings

account.

The sample indicates:

Customer years at residence equals 1 year (e.g. between 0 months and 1 year) Customer years with employer equal 5 years (e.g. between 4 years and 5 years)

Sample 8 9 0 1 2 567890123456789012345678901234567890123 PI196502060000012348400005000000X1 5 YY



Payment Action Format Indicator (PM)


2 A Format Indicator "PM" Constant – Payment action information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Subtype Flag Identifies the type of transaction used in conjunction with the Action Code.

Valid values when MOP = MC or IM: F – Final Authorization P – Pre-Authorization

Notes: This value is only sent to MasterCard and International Maestro. Subtype Flag is defaulted at the transaction division level. All transactions processed through the transaction division carry the default Subtype Flag value unless this field is populated (population of this field overrides the transaction division level default). See Appendix AA: MasterCard Identification of Final Authorizations. Valid values when MOP = PY:

A – Authorization B – Authorization and Create Billing

Agreement (independent of each other) C – Create Billing Agreement E – Order and Create Billing Agreement

(independent of each other) O – Order

Notes: Subtype Flag is also called "Payment Action".

O (Order) should be used for split shipments.

See Appendix S: PayPal for additional information on populating this field.




Payment Action Format Indicator (PM), (Continued)

Notes: MasterCard and International Maestro: See Appendix AA: MasterCard Identification of Final Authorizations.

PayPal: This Format Indicator must be sent when MOP = PY and Action Code = AR or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator must be sent when MOP = PY and Action Code = AU, ED, EG, or ES or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This Format Indicator must be sent when MOP = PY and Action Code = ES or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

See Appendix S: PayPal for product information.

Sample 8 567 PMA



Page Set Up Format Indicator (PS)


2 A Format Indicator "PS" Constant – Page set up information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Locale Code Locale of pages displayed by PayPal during Express Payment. (Optional)

Valid values: AU – Australia DE – Germany ES – Spain FR – France GB – Great Britain IT – Italy JP – Japan US – United States

30 A Page Style Sets the customer payment page style for payment pages associated with this link. This value corresponds to the HTML variable page style for customizing payment pages. (Optional)


6 A Border Color - Header Sets the border color around the header of the payment page. (Optional)

6 A Background Color - Header

Sets the background color for the header of the payment page. (Optional)

6 A Background Color - Payment Page

Sets the background color for the payment page. (Optional)






Page Set Up Format Indicator (PS), (Continued)


Variable 0-127

A Header Image URL for the image that appears at the top left of the payment page. (Optional)

Left justified/blank filled Notes: This Format Indicator can only be sent when MOP = PY or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This Format Indicator is used when MOP = PY and Action Code = ES.

All fields on this Format Indicator have defaults set at the transaction division level. Use this Format Indicator to override any of the defaults. Sending blanks in any field uses the default for the field.

Colors are represented as 6-character hexadecimal values ranging from 000000 (black) to FFFFFF (white): 6 characters each for Red (FF0000), Green (00FF00), and Blue (0000FF).


Sample 8 9 0 1 2 3 5678901234567890123456789012345678901234567890123456789 PSUSPageStyleIs30-charactersToHereFFFFFF0000001A0F3D000



Personal Information 2 Format Indicator (P2)


2 A Format Indicator "P2" Constant – Personal information 2. Specifies this record as an additional processing format of the Merchant Services standard format.

25 A Payer ID Customer account number.

Left justified/blank filled Notes: This Format Indicator can only be sent when MOP = PY, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This Format Indicator must be sent when MOP= PY and Action Code = ED or FA or the transaction rejects with Response Reason Code 225 (Invalid Field Data).



Sample 8 9 0 1 567890123456789012345678901 P2FYA122PZY387



Recipient Data Format Indicator (RD)


2 A Format Indicator "RD" Constant – Debt repayment information. Specifies this record as an additional processing format of the Merchant Services standard format.

8 A Date of Birth of Primary Recipient

Date of birth of the primary recipient. (Optional) YYYYMMDD format

10 A Masked Account Number

Partially masked account number of recipient account. (Optional) Left justified/asterisk filled or all blanks. Note: Blanks are replaced with asterisks. Card-to-Card Payments First 6 and the last 4 digits of the recipient account number, no blanks. Card-to-Non-Card Payments The 10-digit recipient account number.

For example, credit card account to EUDD account.

6 A Partial Postal Code Partial postal code of primary recipient. (Optional) Left justified/blank filled Note: First 6 characters of the primary recipient’s postal code. If the value is less than 6, the field is filled with spaces.

6 A Last Name of Primary Recipient

First 6 characters of the last name of the primary recipient. (Optional) Left justified/asterisk filled or all blanks. Note: Blanks are replaced with asterisks.




Recipient Data Format Indicator (RD), (Continued)

Notes: This Format Indicator should be sent for person-to-person transactions when MCC = 6012 and MOP = VI to avoid additional fees. This Format Indicator is ignored for all other MOPs and MCCs. The debt repayment transactions for MCC 6012 are restricted to Debit Cards only in the EU. In the UK, debt repayment transactions are allowed on all cards, including credit. The Format Indicator is for domestic transactions only. For example:

• UK domestic - UK merchant, UK issued card • Any other EU country domestic - such as, Germany merchant Germany issuer or France

merchant France Issuer Sample 8 9 0 1 5678901234567890123456789012345 RD197205181234567***187 JONES*



Retail Format Indicator (RE)


2 A Format Indicator "RE" Constant – Retail information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 N POS Capability Code Defines the ability of the POS terminal or cash register.

Valid value: 2 – Magnetic stripe reader

2 N POS Entry Mode Indicates how the transaction was entered.

Valid value: 90 – Entire magnetic stripe read and

transmitted

1 N Track Indicator Track that was read.

Valid values: 1 – Track 1 2 – Track 2

Note: If this field is not populated with a “1” or a “2”, the transaction does not reject, but does downgrade as swipe data was not sent to the Issuer.




Retail Format Indicator (RE), (Continued)


76 (T1) 39 (T2)

A Swipe Data Actual data from the card magnetic stripe.

Left justified/blank filled Notes: DO NOT MANIPULATE or alter swipe data in any way.

Start sentinel (%) indicates the initial data position on the track.

End sentinel (?) is the character that follows the final character of data recorded on the track.

Longitudinal Redundancy Check (LRC) is a verification value that ensures that no data has been lost in the stripe reading process. The LRC is equivalent to a check digit of the entire track, including the control characters. The LRC is directly after the end sentinel.

For Bill Me Later Private Label, the start sentinel and end sentinel must be sent with the track data.

• Track 1 Start Sentinel = % (percentage sign)

• Track 2 Start Sentinel = ; (semi colon)

For all other MOPs, the start sentinel, end sentinel and LRC must be removed.

Swipe data must be sent in all upper case.




Retail Format Indicator (RE), (Continued)

Notes: Either Retail Format Indicator (RE) or Retail 3 Format Indicator (R3)can be sent for swipe data.

Retail 3 Format Indicator (R3) must be sent for American Express swipe data.

This Format Indicator or Retail 2 Format Indicator (R2) or Retail 3 Format Indicator (R3) must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If manually keyed, do not use this record; use an Address Format Indicator. Postal code is the minimum requirement to obtain the lowest possible interchange rate.

If manually keyed, do not use this record; US merchants processing USD currency should send the Fraud Format Indicator (FR). Sending Card Security Value on a manually keyed transaction may protect against fraud chargebacks.

When sending Postal Code Only Address Format Indicator (AZ), the postal code sent should be the accountholder's postal code, otherwise some issuers may decline the transaction.

For PIN-Based Debit retail transactions, Track 2 data is used for authorizations, refunds, and reversals.

Qualification for best rates cannot be verified during testing. Contact your Account Executive after the first deposit to verify qualification.

Sample Swipe Data – Track 1 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456 RE2901TRACK1 SWIPE DATA

Sample Swipe Data – Track 2 8 9 0 1 56789012345678901234567890123456789 RE2902TRACK1 SWIPE DATA



Request Information Format Indicator (RI)


2 A Format Indicator "RI" Constant – Request information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Enhanced Verification Flag

Indicates the request of enhanced accountholder information.

Valid values: Y – Enhanced verification requested. N – Enhanced verification is not requested.

Notes: When this field = Y, the Response Information Reply Format Indicator (RI) is returned.

When this field = N, the Response Information Reply Format Indicator (RI) is not returned.

3 A Reserved Blanks Note: Only used when MOP = AX, DD, DI, or JCB.

Sample 8 9 567890 RIY



Reversal Format Indicator – Gift Card Only (RV)


2 A Format Indicator "RV" Constant – Reversal information. Specifies this record as an additional processing format of the Merchant Services standard format.



Variable 1-99

A System Assigned Reference Number

System assigned reference number.

Note: Do not send this Format Indicator if you do not have the System Assigned Reference Number.

Sample 8 9 5678901234567 RV09123456789



Retail 2 Format Indicator (R2)


2 A Format Indicator "R2" Constant – Retail information 2. Specifies this record as an additional processing format of the Merchant Services standard format.

4 N Merchant Category Code (MCC)

Merchant category code used for the authorization. (Optional)

Note: See Appendix T: Soft Merchant Information and Merchant Descriptor for additional information on populating this field.

1 N CAT Type Type of Card Activated Terminal. (Optional)

Valid values: 1 – Automated Dispensing Machine 2 – Self Service Terminal 3 – Limited Amount Terminal

8 A Terminal ID Identifies a processing device associated to a Point of Sale division. (Optional)


Notes: American Express highly recommends merchants send this field for non-U.S. and non-Canadian transactions as it is used by the Issuer at authorization time.

MasterCard requires a unique terminal identifier for each device on card present authorizations when a merchant has multiple devices (e.g. cash register, fuel pump) at a location to identify where the transaction originated.

This field must be sent when the transaction contains EMV data or the transaction rejects with Response Reason Code 225 (Invalid Field Data).




Retail 2 Format Indicator (R2), (Continued)

Notes: This is not a required Format Indicator for non-EMV retail transactions.

This Format Indicator must be sent when the transaction contains EMV data or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator or the Retail (RE) Format Indicator or the Retail 3 (R3) Format Indicator must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

Sample 8 9 567890123456789 R245512ABC123





2 A Format Indicator "R3" Constant – Retail information 3. Specifies this record as an additional processing format of the Merchant Services standard format.

1 N POS Capability Code Defines the ability of the POS terminal or cash register. Valid values:

0 – Magnetic stripe reader and key entry

1 – Magnetic stripe reader, key entry and chip reader

2 – Magnetic stripe reader only (e.g. CAT)

3 – Magnetic stripe reader and chip reader only

4 – Optical character recognition

5 – Key entry only (electronic commerce, Direct Marketing/MOTO)

6 – Contactless or Magnetic Stripe entry (Required for Amex Express Pay qualification). This value, or a 7, must be used for a Discover or Discover Diners ZIP transaction.

7 – Magnetic stripe reader, key entry, chip reader and RFID reader. This value, or a 6, must be used for a Discover or Discover Diners ZIP transaction.

Note: This value is used for Chase Pay and Visa POS Transactions.

8 – Terminal is only QR Code capable






2 N POS Entry Mode Indicates how the transaction was entered. Valid values:

01 – Manual Entry/No Mag stripe 02 – Mag stripe read, but full, unaltered contents

not provided. This is only to be used when the terminal is not CVV/CVC compliant.

03 – QR code read (Visa and ChaseNet only) Barcode read (American Express, Discover, Diners and JCB only)

Note: This value is used for Chase Pay POS transactions.

04 – OCR / MICR coding read 05 – Chip card read via chip reader, track data

reliable (American Express, ChaseNet, Discover, International Maestro, JCB, MasterCard and Visa only)

06 – Driver Licensed swiped (future) 07 – Contactless Chip card read via chip reader

(American Express, ChaseNet, Interac Flash, International Maestro, MasterCard and 91 or 81 can be used in the request. 81 is provided in the response.

79 – Chip card, fall back to manually entered (MC/International Maestro only)

80 – Chip card, fall back to magnetic stripe read (MC/International Maestro only)

81 – Contactless or magnetic stripe read and full, unaltered contents provided (Discover only). Either 91 or 81 can be used in the request. 81 is provided in the response.

83 – Radio Frequency Identification Indicator – Chip

90 – Magnetic stripe read and full, unaltered contents provided






POS Entry Mode, (Continued)

Valid values, (Continued): 91 – Contactless or magnetic stripe read and

full, unaltered contents provided (American Express, ChaseNet, Debit, Discover, International Maestro, MasterCard and Visa only)

Required for Amex Express Pay qualification. For Discover: either 91 or 81 can be used in the request. 81 is provided in the response.

95 – Chip card read via chip reader, track data unreliable (ChaseNet and Visa only) – this value is applicable to responses only.

1 N Track Indicator Track that was read. Valid values:

1 – Track 1 2 – Track 2

Note: If this field is not populated with a “1” or a “2”, the transaction does not reject, but does downgrade as swipe data was not sent to the Issuer.

For Chase Pay POS this field should be populated with a value of 2.


Valid values: 01 - 76

Variable 1-76

A Swipe Data Actual data from the card magnetic stripe.

Left justified/blank filled Notes: DO NOT MANIPULATE or alter swipe data in any way.

Start sentinel (%) indicates the initial data position on the track.

End sentinel (?) is the character that follows the final character of data recorded on the track.






Swipe Data, (Continued)

Notes, (Continued)

Longitudinal Redundancy Check (LRC) is a verification value that ensures that no data has been lost in the stripe reading process. The LRC is equivalent to a check digit of the entire track, including the control characters. The LRC is directly after the end sentinel.

For Bill Me Later Private Label, the start sentinel and end sentinel must be sent with the track data.

• Track 1 Start Sentinel = % (percentage sign)

• Track 2 Start Sentinel = ; (semi colon)

For all other MOPs, the start sentinel, end sentinel and LRC must be removed.

Chase Pay POS (Show)

This field must be populated with the value received in EMV tag 57 read from the QR code.

Chase Pay POS (Scan)

This field must be populated with the <track2Equivalent> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

Swipe data must be sent in all upper case.





Notes: Either Retail Format Indicator (RE) or Retail 3 Format Indicator (R3) can be sent for swipe data.

Retail 3 Format Indicator (R3) must be sent for American Express swipe data.

If the transaction contains EMV data and this format indicator is not sent then the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator or the Retail (RE) Format Indicator or the Retail 2 (R2) Format Indicator must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If manually keyed for non-EMV transactions, do not use this record; use an Address Format Indicator. Postal code is the minimum requirement to obtain the lowest possible interchange rate.

If manually keyed for non-EMV transactions, do not use this record; US merchants processing USD currency should send the Fraud Format Indicator (FR). Sending Card Security Value on a manually keyed transaction may protect against fraud chargebacks.

When sending Postal Code Only Address Format Indicator (AZ), the postal code sent should be the accountholder's postal code, otherwise some issuers may decline the transaction.

For non-EMV PIN-Based Debit retail transactions, Track 2 data is used for authorizations, refunds, and reversals.

Qualification for best rates cannot be verified during testing. Contact your Account Executive after the first deposit to verify qualification.

Sample 8 9 0 1 56789012345678901234567890123 R3290221TRACK DATA 0123456789



Soft Merchant Information Format Indicator (SM)


2 A Format Indicator "SM" Constant – Soft merchant location information. Specifies this record as an additional processing format of the Merchant Services standard format.

38 A DBA Merchant "Doing Business As" name. (Optional)

Left justified/blank filled Notes: Only the first 25 bytes are sent to ChaseNet, Visa, and the EBT and PIN-Debit Networks. Only the first 22 bytes are sent to Discover, International Maestro, and MasterCard.

For OCT, the format is:

MERCHANT *SENDER

A space must precede *SENDER.

38 A Street Merchant street address where the transaction took place. (Optional)


Notes: Only the first 25 bytes are sent to the EBT and PIN-Debit Networks. Only used by American Express and the EBT and PIN-Debit Networks.

21 A City Merchant city where the transaction took place. (Optional)


Notes: This must be the actual seller’s city location. Only the first 13 bytes are sent to ChaseNet, Discover, and Visa. Only the first 15 bytes are sent to the EBT and PIN-Debit Networks.

3 A Region Merchant state/province where the transaction took place. (Optional)





Soft Merchant Information Format Indicator (SM), (Continued)


Region, (Continued) Continued:

Note: For U.S. merchants processing ChaseNet, MasterCard, and Visa, this must be a valid U.S. state or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

15 A Postal Code Merchant zip/postal code where the transaction took place. (Optional)


Note: Chase recommends that this field be sent by American Express oil industry merchants.

3 A Country Code Merchant numeric ISO country code where the transaction took place. (Optional)


Note: Only used by American Express and the EBT and PIN-Debit Networks.

15 A Merchant ID Merchant’s location ID. (Optional)


Notes: American Express oil industry merchants should supply station location (11 bytes). If the station location is supplied, but is not exactly 11 bytes, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Only the first 8 bytes are sent to EBT and PIN-Debit Networks. Only used by American Express, MasterCard, EBT and PIN-Debit Networks.

MasterCard strongly recommends this field be populated.



Right justified/zero filled or blanks




Soft Merchant Information Format Indicator (SM), (Continued)

Notes: American Express Aggregators must send the Soft Merchant Information 2 (S2) Format Indicator or the Soft Merchant Information 3 (S3) Format Indicator.

The Format Indicator Soft Merchant Information 3 (S3) is preferred if merchant phone and email are to display on cardholder’s statement. City no longer displayed.

This Format Indicator or the Soft Merchant Information 2 (S2) Format Indicator or the Soft Merchant Information 3 (S3) Format Indicator must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

See Appendix T: Soft Merchant Information and Merchant Descriptor for additional information.

Sample 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456789 SMMERCHANT DBA 4 NORTHEASTERN BLVD SALEM

7 8 9 0 1 2 012345678901234567890123456789012345678901234567890123 NH 03079 84012345678901 6038



Split Tender Format Indicator (ST)


2 A Format Indicator "ST" Constant – Split tender information. Specifies this record as an additional processing format of the Merchant Services standard format.

1 A Split Tender Indicator Indicates whether the transaction is a split tender transaction. (Optional)

Valid values: N – No Y – Yes " " – Blank

Note: If this field is blank, N is used as the default value.

Note: This Format Indicator may be sent when MOP = C9, but it is ignored.

Sample 8 567 STY



Soft Merchant Information 2 Format Indicator (S2)


2 A Format Indicator "S2" Constant – Soft merchant location information. Specifies this record as an additional processing format of the Merchant Services standard format.

38 A DBA Merchant "Doing Business As" name. (Optional) Left justified/blank filled Notes: For American Express, only the first 19 alphabetic and numeric bytes are sent to American Express.

Example of populated field: AGGREGATOR*ACTUAL SELLER NAME Example of bytes sent to American Express: AGGREGATORACTUALSEL

Only the first 25 bytes are sent to ChaseNet, Visa, and the EBT and PIN-Debit Networks.

Only the first 22 bytes are sent to Discover, International Maestro, and MasterCard.


MERCHANT *SENDER


38 A Street Merchant street address where the transaction took place. (Optional) Left justified/blank filled Notes: Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's street address.




Soft Merchant Information 2 Format Indicator (S2), (Continued)


Street, (Continued) Notes, (Continued) For American Express aggregators, only the first 20 bytes are sent.

Only the first 25 bytes are sent to the EBT and PIN-Debit Networks. Only used by American Express and the EBT and PIN-Debit Networks.


Left justified/blank filled Notes: This must be the actual seller’s city location. Only the first 13 bytes are sent to ChaseNet, Discover, and Visa. Only the first 15 bytes are sent to the EBT and PIN-Debit Networks.

3 A Region Merchant state/province where the transaction took place. (Optional) Left justified/blank filled

Note: For U.S. merchants processing ChaseNet, MasterCard, and Visa, this must be a valid U.S. state or the transaction rejects with Response Reason Code 225 (Invalid Field Data).





Length Data Type

Field Name Comments

15 A Postal Code Merchant zip/postal code where the transaction took place. (Optional) Left justified/blank filled

Notes: Merchant Services recommends that this field be sent by American Express Oil merchants. Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's postal code.

3 A Country Code Merchant numeric ISO country code where the transaction took place. (Optional) Left justified/blank filled Note: Only used by American Express and the EBT and PIN-Debit Networks.

20 A Merchant/Seller ID Merchant location ID. (Optional)


Notes: American Express oil industry should supply station location (11 bytes). If the station location is supplied, but is not exactly 11 bytes, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

For American Express Aggregators, all 20 alphabetic and numeric bytes are sent to American Express.

Example of populated field: SELLER 1234-AB567890 Example of bytes sent to American Express: 34AB567890





Length Data Type

Field Name Comments

20 A Merchant/Seller ID Notes, (Continued)

Only the first 8 bytes are sent to EBT and PIN-Debit Networks. Only used by American Express, MasterCard, EBT and PIN-Debit Networks. MasterCard strongly recommends this field be populated. MasterCard uses only the first 15 bytes.




Note: Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's MCC.

Notes: This Format Indicator or Soft Merchant Information 3 Format Indicator (S3) should be sent by oil industry merchants processing American Express.

This Format Indicator or Soft Merchant Information 3 Format Indicator (S3) must be sent by aggregators processing American Express or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator or the Soft Merchant Information (SM) Format Indicator or the Soft Merchant Information 3 (S3) Format Indicator must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

The Format Indicator Soft Merchant Information 3 (S3) is preferred if merchant phone and email are to display on cardholder’s statement. City no longer displayed.


See Appendix W: American Express for additional information.

Sample 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456789 S2MERCHANT DBA 4 NORTHEASTERN BLVD SALEM

7 8 9 0 1 2 01234567890123456789012345678901234567890123456789012345678 NH 03079 8401234567890135791 6038







Left justified/blank filled Notes: For American Express Aggregators, only the first 19 alphabetic and numeric bytes are sent to American Express.



Only the first 22 bytes are sent to Discover, International Maestro, and MasterCard. For OCT, the format is:

MERCHANT *SENDER




Notes: Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's street address.





Length Data Type

Field Name Comments

Street, (Continued) Notes, (Continued)

For American Express aggregators, only the first 20 bytes are sent.




Notes: This must be the actual seller’s city location.

Only the first 13 bytes are sent to ChaseNet, Discover, and Visa.

Only the first 15 bytes are sent to the EBT and PIN-Debit Networks.


Note: For U.S. merchants processing MasterCard and Visa, this must be a valid U.S. state or the transaction rejects with Response Reason Code 225 (Invalid Field Data).



Notes: Merchant Services recommends that this field be sent by American Express Oil merchants.

Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's postal code.





Length Data Type

Field Name Comments




20 A Merchant/Seller ID Merchant location ID. (Optional) Left justified/blank filled Notes: American Express oil industry should supply station location (11 bytes). If the station location is supplied, but is not exactly 11 bytes, the transaction rejects with Response Reason Code 225 (Invalid Field Data).


For American Express Aggregators, all 20 alphabetic and numeric bytes are sent to American Express for authorizations.


Only used by American Express, MasterCard, EBT and PIN-Debit Networks. MasterCard strongly recommends this field be populated.

MasterCard uses only the first 15 bytes.





Length Data Type

Field Name Comments





19 A Email Address Merchant email address. (Optional)

Left justified/blank filled Note: Characters are acceptable (e.g. dots).

13 A Telephone Number Merchant telephone number. (Optional)


Note: Only the first 10 bytes, after the removal of any dashes, are sent to American Express.





Notes: This Format Indicator, Soft Merchant Information 2 Format Indicator (S2), or Soft Merchant Information 4 Format Indicator (S4) should be sent by oil industry merchants processing American Express.

This Format Indicator, Soft Merchant Information 2 Format Indicator (S2), or Soft Merchant Information 4 Format Indicator (S4) must be sent by aggregators processing American Express or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator, the Soft Merchant Information (SM) Format Indicator or the Soft Merchant Information 2 (S2) Format Indicator, or Soft Merchant Information 4 Format Indicator (S4) must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This format indicator is preferred if merchant phone and email are to display on cardholder’s statement. City no longer displayed.




7 8 9 0 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 NH 03079 8401234567890135791 6038







Left justified/blank filled Notes: For American Express Aggregators, only the first 19 alphabetic and numeric bytes are sent to American Express.



Only the first 22 bytes are sent to Discover, International Maestro, and MasterCard.


MERCHANT *SENDER








Length Data Type

Field Name Comments

Street, (Continued) Notes: Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's street address.

For American Express aggregators, only the first 20 bytes are sent.




Notes: This must be the actual seller’s city location.

Only the first 13 bytes are sent to ChaseNet, Discover, and Visa.

Only the first 15 bytes are sent to the EBT and PIN-Debit Networks.


Note: For U.S. merchants processing MasterCard and Visa, this must be a valid U.S. state or the transaction rejects with Response Reason Code 225 (Invalid Field Data).







Length Data Type

Field Name Comments

Postal Code, (Continued)

Notes: Merchant Services recommends that this field be sent by American Express Oil merchants.

Required for American Express Aggregators or the transaction rejects with Response Reason Code 225 (Invalid Field Data). This must be the actual seller's postal code.




20 A Merchant/Seller ID Merchant location ID. (Optional) Left justified/blank filled Notes: American Express oil industry should supply station location (11 bytes). If the station location is supplied, but is not exactly 11 bytes, the transaction rejects with Response Reason Code 225 (Invalid Field Data).


For American Express Aggregators, all 20 alphabetic and numeric bytes are sent to American Express for authorizations.






Length Data Type

Field Name Comments

Merchant/Seller ID, (Continued)

Notes, (Continued) Only used by American Express, MasterCard, EBT and PIN-Debit Networks. MasterCard strongly recommends this field be populated.

MasterCard uses only the first 15 bytes.





40 A Email Address Merchant email address. (Optional)

Left justified/blank filled Note: Characters are acceptable (e.g. dots).

20 A Contact Telephone Number

Merchant telephone number. (Optional)

Left justified/blank filled Note: If all 20 digits of the telephone number are sent, the full 20 bytes is sent to American Express. If dashes are sent, only the first 17 bytes, after the removal of any dashes, are sent to American Express.





Notes: This Format Indicator, Soft Merchant Information 2 Format Indicator (S2), or Soft Merchant Information 3 Format Indicator (S3), should be sent by oil industry merchants processing American Express.

This Format Indicator, Soft Merchant Information 2 Format Indicator (S2), or Soft Merchant Information 3 Format Indicator (S3), must be sent by aggregators processing American Express or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This Format Indicator, the Soft Merchant Information (SM) Format Indicator or the Soft Merchant Information 2 (S2) Format Indicator, or Soft Merchant Information 3 Format Indicator (S3), must be sent when MOP = EB, or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This format indicator is preferred if merchant phone and email are to display on cardholder’s statement. City no longer displayed.




7 8 9 0 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 NH 03079 8401234567890135791 6038



Token ID Format Indicator (TI)


2 A Format Indicator "TI" Constant – Token ID information. Specifies this record as an additional processing format of the Merchant Services standard format.

20 A Token ID Time stamped token.


Note: This Format Indicator must be sent when MOP = PY and Action Code = ED or EG or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 5678901234567890123456 TI194829A12375Z1923847



URL and Address Flag Format Indicator (US)


2 A Format Indicator "US" Constant – URL and address flag information. Specifies this record as an additional processing format of the Merchant Services standard format.


Valid values: 001 –256

Variable 001-256

A Return URL URL to which the accountholder’s browser is returned after choosing to pay with PayPal.




Variable 001-256

A Cancel URL URL to which the accountholder’s browser is returned after choosing not to pay with PayPal.


1 A Request to Confirm Address

Indicates if the accountholder’s addresses need to be confirmed.

Valid values: A – Confirm billing and shipping addresses B – Confirm billing address Y – Confirm shipping address N – Do not confirm any addresses




URL and Address Flag Format Indicator (US), (Continued)

Length Data Type

Field Name Comments

1 A No Shipping Address Display

Indicates if the shipping address should be displayed on the pay page.

Valid values: Y – Do not display shipping address N – Display shipping address

Note: When No Shipping Address Display = N, the customer sees their PayPal shipping address when they log into their PayPal account, but they cannot change it.

Notes: This Format Indicator can only be sent when MOP = PY, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

This Format Indicator must be sent when MOP = PY and Action Code = ES, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Sample 8 9 0 1 2 3 4 5678901234567890123456789012345678901234567890123456789012 US021MERCHANTORDERPAGE.COM027MERCHANTORDERCANCELPAGE.COMYN



Visa Authentication Format Indicator (VA)


2 A Format Indicator "VA" Constant – Verified by Visa information. Specifies this record as an additional processing format of the Merchant Services standard format.

40 A Transaction ID (XID) Unique tracking number set by the merchant and sent to the Issuer Authentication/Service in the Authentication Request message. (Optional) Left justified/blank filled

Verified by Visa This is the same format used by ChaseNet and Visa when returning XID data to the merchant during the authentication step.

Notes: Must be sent in Base 64 encoding or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For token based transactions that are authenticated with Verified by Visa/3-D Secure, populate this field with the token cryptogram, also known as the TAVV-Token Authentication Verification value.


Consumer Digital Payment Token If populated, the XID data is passed to ChaseNet or Visa.

Notes: Must be sent in Base 64 encoding or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).





Visa Authentication Format Indicator (VA), (Continued)


40 A Cardholder Authentication Verification Value (CAVV)

Verified by Visa Cryptographic value derived (Base 64 Encoded) with an algorithm that applies the Issuer’s private key to the combination of the Account number, the Transaction Identifier (XID), and other data.

This is the same format used by ChaseNet and Visa when returning CAVV data to the merchant during the authentication step.




Consumer Digital Payment Token





For original authorizations, this field is required and must be a valid Base 64 value.

For subsequent authorizations (i.e., split/delayed shipments), this field must be a valid Base 64 value or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).







40 A Cardholder Authentication Verification Value (CAVV), (Continued)

Notes, (Continued): Chase Pay Unique <paymentCryptogram> value returned from the Chase Pay Service.


Notes: For original and subsequent (i.e., split/delayed shipments) authorizations, populate this field with the value returned from Chase Pay Service. Do Not Manipulate this value in any way or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

This value is returned from the Chase Pay Service in Base 64 Encoding.

For recurring authorizations, Transaction Type must equal 2 and this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data)





Notes: Verified by Visa When using this Format Indicator, the Transaction Type field should be populated with the ECI value and the CAVV value that the merchant received back from the merchant plug-in software.

This Format Indicator can be sent when MOP = CR, CZ, VI, or VR.

See Appendix H: Verified by Visa for more information.

Consumer Digital Payment Token When using this Format Indicator the Transaction Type field must be populated with 2 (HCE and non-HCE), 5 (non-HCE), or 7 (HCE) or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

When using this Format Indicator for authorizations, the Cardholder Authentication Verification Value (CAVV) is required.

See Appendix AM: Consumer Digital Payment Token for more information.

Chase Pay

When using this Format Indicator the Transaction Type field should be populated with a 2 (for recurring transactions) or the <eciIndicator> value returned from the Chase Pay Service.

When using this Format Indicator for authorizations, the Cardholder Authentication Verification Value (CAVV) is required.

This Format Indicator can be sent when MOP = CR, CZ, or VI.

See Appendix AN: Chase Pay for more information.

Samples

Verified by Visa 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456 VAEARF234521Y= 4523643286389=

Chase Pay 8 9 0 1 2 3 4 5 6 5678901234567890123456789012345678901234567890123456789012345678901234567890123456 VA 123456789012345678921234567=



Various Text Format Indicator (VT)


2 A Format Indicator "VT" Constant – Various text information. Specifies this record as an additional processing format of the Merchant Services standard format.



Variable 1-90

A Text Message Text used to clarify the transaction.

Left justified/blank filled, cannot be all blanks.

Sample 8 9 0 5678901234567890 VT12TEXT MESSAGE



American Express Authentication Format Indicator (XA)


2 A Format Indicator "XA" Constant – American Express authentication information.


40 A American Express Authentication Verification Value (AEVV) (Block A)







When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in this field and the second block of data must be populated in the Transaction ID (XID) field. Must be sent in a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).




American Express Authentication Format Indicator (XA), (Continued)


American Express Authentication Verification Value (AEVV) (Block A), (Continued)

Notes, (Continued)

For original authorizations, this field is required. For subsequent authorizations (i.e., split/delayed shipments), this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For recurring authorizations,Transaction Type must equal 2 and this field must be populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

40 A Transaction ID (XID) (Block B)






When sending 28-byte Base 64 or 20-byte binary (hexadecimal ASCII character) format, the American Express Authentication Verification Value (AEVV) field is populated with the value. This field should be blank filled.

When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in the American Express Authentication Verification Value (AEVV) field and the second block of data must be populated in this field.






Transaction ID (XID) (Block B), (Continued)

Notes, (Continued)

Must be sent in a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For original authorizations, this field is required and the Transaction Type must be 5 or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For subsequent authorizations (i.e., split/delayed shipments), this field must be blank when Transaction Type = 5 and the American Express Authentication Verification Value (AEVV) (Block A) populated with “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For recurring authorizations, this field must be blank when Transaction Type = 2 or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).





Notes: This Format Indicator should only be sent for American Express Consumer Digital Payment Token transactions.

When using this Format Indicator the Transaction Type field must be populated with a “2” or a “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The cryptogram is either:


or • 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format


When sending a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format, this value must be split into two equal blocks of data. The first block of data must be populated in this field and the second block of data must be populated in the Transaction ID (XID) field. If the fields are not populated in either a valid Base 64 or a binary (represented as hexadecimal ASCII characters) value, the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).


Sample for American Express Authorization 8 9 0 1 2 567890123456789012345678901234567890123456 XASUBSEQUENT000000000000000000



Online Processing Return Format Record


1 1 A Record Type Constant "T"

2,3 2 N Format Constant

Constant "74"

4 1 A Constant Constant "V"

5,26 22 A Merchant’s Order Number

Merchant’s order number (echoed back from Online Processing Detail Record).

27,29 3 N Response Reason Code

Result of action requested.

See Appendix A: Response Reason Code Description/Usage

30,35 6 N Response Date

The date the response was obtained.

YYMMDD format (Eastern Time Zone)

Note: Should be stored and supplied in the deposit file.

36,41 6 A Authorization / Verification Code

Issued by the bank or service establishment.


Notes: Should be stored and supplied with the deposit transaction.

When Action Code = VF, this field may or may not be populated.

Debit transactions could return blanks or "N/A".

ECP transactions return "123456".

European Direct Debit transactions return "ED1234".

Gift Card transactions could return blanks.

MoneyPak transactions return blanks.

PayPal transactions return blanks.

Shop with Points transactions return blanks when Action Code = BI, ET, HC, or UT.




Online Processing Return Format Record, (Continued)


42,43 2 A AVS Response Code

Response to address verification request.

Notes: When MOP = AX, and Enhanced Verification Flag = Y, located on the Request Information Format Indicator (RI), this field is blank.

However, if the inbound address information does not pass Merchant Services edit checks, this field may be populated.

See Appendix B: Address Verification

44 1 A Card Security Value Response Code

Code returned by the card Issuer in response to a card security verification request.

Valid values: M – Value matched (American Express,

ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, Visa)

N – Value not matched (American Express, ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, Visa)

P – Not processed (American Express, ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, Visa)

S – Should be on the card (ChaseNet, Discover, Discover Diners, Gift Card, JCB, Visa)

U – Unsupported by the Issuer ChaseNet, (Discover, Discover Diners, International Maestro, JCB, MasterCard, Visa)

I – Invalid (American Express, ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, Visa)

" " – Blank (American Express, Bill Me Later Private Label, JCB – Non U.S. Dollar, or when Card Security Value is not sent with the transaction)






Card Security Value Response Code, (Continued)

Notes: For Gift Card, this field could be populated even if a CVD2 value was not sent in the Online Processing Detail Record.

Discover may return “S” on authorizations sent without Card Security Value.

45,63 19 A Account Number

Account number (echoed back from Online Processing Detail Record).

Notes: Approved Bill Me Later and Bill Me Later Private Label transactions return a 16-byte Bill Me Later account number.

For MoneyPak, if the Account Number is 20 bytes, this field is blank.

Approved PayPal transactions could return an account number containing dashes.

See Appendix S: PayPal for additional information on how this field is populated.

64,67 4 A Expiration Date

MMYY format (echoed back from Online Processing Detail Record).

Note: Could be returned as blanks for ChaseNet, MasterCard, and Visa transactions.





Position Length Data Type

Field Name Comments

68,69 2 A Method of Payment (MOP)

Defines the MOP associated with this order. Valid values:

AE – ACCEL PIN-Based Debit AF – AFFN PIN-Based Debit AP – ACCEL PINLess Debit AT – ATH PIN-Based Debit AX – American Express BL – Bill Me Later BP – Bill Me Later Private Label C9 – Shop with Points CR – ChaseNet - Signature Debit/Prepaid CU – CU24 PIN-Based Debit CX – ChaseNet PIN-Based Debit CZ – ChaseNet - Credit DD – Discover Diners DE – Generic PIN-Based Debit DI – Discover DP – Generic PINless Debit EB – Electronic Benefits Transfer EC – Electronic Check ED – European Direct Debit EN – Encryption IL – Interlink PIN-Based Debit IM – International Maestro JC – JCB JN – Jeanie PIN-Based Debit MC – MasterCard MR – MasterCard Canadian Domestic Restricted

Debit MP – MoneyPak MT – Maestro PIN-Based Debit NP – NYCE PINless Debit NY – NYCE PIN-Based Debit PP – Pulse PINless Debit PS – Pulse PIN-Based Debit PY – PayPal SP – Star PINless Debit SR – Star PIN-Based Debit SV – Gift Card SZ – Shazam PIN-Based Debit VI – Visa VR – Visa Canadian Domestic Restricted Debit







Notes: (continued)

Notes: For an encrypted transaction, the return record includes the actual method of payment. If decryption of Account Number fails, this field is blank.

For merchants enabled for ChaseNet MOP reassignment, when transactions are sent with MOP = VI, MOP = CR or CZ could be returned in the reply record.

If card prefix 30, 36, 38, or 39 are sent as Discover or MasterCard, Merchant Services processes and reports the transaction as Discover Diners. MOP = DD is returned in the reply records. For U.S. merchants processing non-USD currency or Canadian merchants processing in non-Canadian currency, if card prefix 36 is sent as MasterCard, Merchant Services rejects the transaction with Response Reason Code 239 (Invalid MOP for Transaction Division).

If card prefix 6759 or 6767 are sent as UK Domestic Maestro, Merchant Services processes and reports the transaction as International Maestro. MOP = IM is returned in the reply record.

MOP = VR should only be used by Canadian domiciled merchants processing Canadian issued cards. When these accounts are sent with MOP = VI, Merchant Services processes and reports the transaction as Visa Canadian Domestic Restricted Debit. MOP = VR is returned in the reply records. Debit Notes: All successful PIN-Based and PINless Debit transactions are returned with the specific MOP the transaction was processed under. This specific MOP must be sent at deposit time or the transaction rejects with Response Reason Code 741 (Validation Failed).







Notes: (continued)

All unsuccessful transactions could be returned with the specific MOP or a generic MOP (DE or DP). When Action Code = FA and MOP = DE or DP, this field value is echoed back from the Online Processing Detail Record. For merchants enabled for Merchant Services’ PINless Debit BIN File Management Product, If the transaction is processed as debit, the specific debit network MOP is returned in the response. For merchants enabled for Merchant Services’ PINless Debit BIN File Management Product, if the transaction is processed as credit, ChaseNet, MasterCard, or Visa MOP is returned in the response.

70,71 2 N Payment Advice Code

Payment advice code.

Valid values: 01 – New account information available.

Obtain new account information. 02 – Try again later. Recycle transaction in

72 hours. 03 – Do not try again. Obtain another type of

payment from customer. 21 – Do not try again. Issuer has blocked

recurring payment transaction. " " – Blanks






72 1 A CAVV Response Code

This field is populated for any Verified by Visa or Consumer Digital Payment Token transaction. Valid values:

0 – CAVV Not Validated due to erroneous data submitted.

1 – CAVV Failed Validation – Authentication Transaction

• Indication of potential bad or fraudulent data submitted as the CAVV.

2 – CAVV Passed Validation – Authentication Transaction

3 – CAVV Passed Validation – Attempted Authentication Transaction.

Determined that the Issue ACS generated this value from the use of the Issuer’s CAVV key(s).

4 – CAVV Failed Validation – Attempted Authentication • Indication of potential bad or

fraudulent data submitted as the CAVV.

• Determined that Visa generated this value from the use of CAVV key(s).

5 – Reserved for future use – NOT USED.






CAVV Response Code, (Continued)

Valid values, (Continued): 6 – CAVV Not Validated

• Issuer not participating in CAVV validation.

• This value is generated when an Issuer requests the “do not verify” flag to be established for its BINs.

• This parameter enables an Issuer to temporarily stop CAVV verification while resolving CAVV key issues.

• ChaseNet and Visa process this value as a valid CAVV.

7 – CAVV Failed Validation – Attempted Authentication Transaction • This is an indication of potential bad

or fraudulent data submitted as the CAVV.

• CAVV generated with Visa Key. 8 – CAVV Passed Validation – Attempted

Authentication Transaction • CAVV generated with Visa Key.

9 – CAVV Failed Validation – Attempted Authentication Transaction • This is an indication of potential bad

or fraudulent data submitted as the CAVV.

• CAVV generated with Visa Key • Issuer ACS unavailable.

A – CAVV Passed Validation – Attempted Authentication Transaction • CAVV generated with Visa Key • Issuer ACS unavailable.






CAVV Response Code, (Continued)

Valid values, (Continued): B – CAVV Passed Validation – Attempted

Authentication Transaction. • No liability shift. • Indication that the account number is

a pre-paid gift card or that the ECI provided with the authorization was a 7.

C – CAVV Not Validated – Attempted Authentication Transaction. • Issuer did not return a CAVV results

code in the authorization response. • ChaseNet and Visa treat this as valid

CAVV if the Issuer approves the authorization.

D – CAVV Not Validated – Authentication • Issuer did not return a CAVV results

code in the authorization response. • ChaseNet and Visa treat this as valid

CAVV if the Issuer approves the authorization.

I – Invalid Security Data. U – Issuer does not participate or 3-D Secure

data not utilized. " " – Blank

Notes: CAVV is supported for the ChaseNet Methods of Payment. For Consumer Digital Payment Token, the only values returned are 0, 1, 2, I, or Blank.

73,84 12 N Amount Amount of transaction (echoed back from Online Processing Detail Record).

Two decimal implied/right justified/zero filled Note: A carriage return (↵) indicates the end of a transaction and any Reply Format Indicators are sent before the carriage return (↵).



Return Response Processing Formats

The following Reply Format Indicators may be returned sequentially, in any order, beginning in position 85. The Reply Format Indicator may not be returned with front-end rejects.



Record Layout Page

Number AB Bill To Address 139 Bill to address 203 AL Email Address 53 Email address 205 AS Ship To Address 139 Ship to address 206 AV ECP Advanced

Verification 22 Return Account Status and

Account Owner Authentication responses for approved merchants

208

BM Bill Me Later 93 Bill Me Later 217 BQ Balance Inquiry 14 Return current balance for

MoneyPak 219

BR Bill Me Later Private Label 26 New account information assigned by BillMeLater

220

BX Balance Inquiry 2 15 Balance Inquiry 2 221 CO Cash Back 26 Approved cash received in

addition to purchase 222

CS Card Issuing Country Status

5 Indicates the status and country code

223

CT01 Card Type Indicator 15 Card Type Indicator (Version 1) 224 CT02 Card Type Indicator 16 Card Type Indicator (Version 2) 227 CP Chip EMV® 6-1004 Response Information Format

Indicator 230

DB Debit Information 34 Debit Information – Debit ONLY (PIN-Based or PINless)

231

DN Digital PAN 39 Digital PAN 232 E2 European Direct Debit 2 47 European Direct Debit including

IBAN 233

EBT Electronic Benefits Transfer

Variable Food Stamp or Cash Benefits 234

FC Gift Card 82 Balances and Reference Number 236 FX Access FX Cross

Currency 71 Access FX Cross Currency 240

F1 Gift Card Block Activation 61 Block Activation 243 KR Rules Triggered 10 -1004 Rules Triggered 244

KT01 Fraud Scoring 1 43 Fraud Scoring (Short) 245 KT02 Fraud Scoring 2 220 Fraud Scoring (Long) 247 ME Merchant Echo 4 – 103 Merchant Echo 255 MP MoneyPak 67 MoneyPak 256 MT Message Type Records 49 Message Type Records 257




Return Response Processing Formats, (Continued) The following Reply Format Indicators may be returned sequentially, in any order, beginning in position 85. The Reply Format Indicator may not be returned with front-end rejects.



Record Layout Page

Number PB Partial Authorization 26 Partial Authorization Reply 258 P2 Personal Information 2 29 Personal Information 2 259 RI Response Information 12 Response Information 260 RM Response Message 5 – 94 Response Message 263 SI Shop with Points

Information 31 Shop with Points Information 264

SP Shop with Points 75 Shop with Points 265 TI Token ID 22 Token ID 267 TX Transaction ID 21 Transaction ID 268 VI Visa Transaction ID 47 Visa Transaction Identifier 269


RECORD LAYOU167TS, (Continued)

Bill To Address Reply Format Indicator (AB)


2 A Format Indicator "AB" Constant – Bill to Address information. Specifies this record as an additional processing reply format of the Merchant Services standard format.






Note: When MOP = PY, the format is AAA-EEE-NNNN.

30 A Name Text Accountholder’s name. (Optional)


Note: When MOP = PY, this value could be an accountholder's first name and business name if it is a corporate account (instead of last name).





2 A Country Code Accountholder’s country code. (Optional)

20 A City Accountholder’s city. (Optional)





Bill To Address Reply Format Indicator (AB), (Continued)


2 A State Accountholder’s state. (Optional)


10 A Postal Code Accountholder’s postal code. (Optional)


Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 ABH6038968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 USSALEM NH03079



Email Address Reply Format Indicator (AL)


2 A Format Indicator "AL" Constant – Email address information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

1 A Address Subtype Type of email address.

Valid value:

B – Bill To/Buyer Email Address

50 A Email Address Email address.


Note: Special characters are acceptable (e.g. dots).

Note: This Reply Format Indicator is returned when MOP = PY and Action Code = EG.

Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901234567 [email protected]



Ship To Address Reply Format Indicator (AS)


2 A Format Indicator "AS" Constant – Ship to address information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

1 A Telephone Type Phone number of ship to recipient. (Optional)





30 A Name Text Ship to name. (Optional)






2 A Country Code Ship to country code. (Optional)

20 A City Ship to city. (Optional)


2 A State Ship to state. (Optional)





Ship To Address Reply Format Indicator (AS), (Continued)


10 A Postal Code Ship to postal code. (Optional)

Left justified/blank filled Note: This Reply Format Indicator is returned when MOP = PY, Action Code = EG and Format Indicator = AS and/or HN were sent on the transaction or PayPal returns the ship to address.

Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 ASD603898000 JOHN D. *SMITH 4 NORTHEASTERN BLVD

6 7 8 9 0 1 2 0123456789012345678901234567890123456789012345678901234567890123 USSALEM NH03079



ECP Advanced Verification Reply Format Indicator (AV)


2 A Format Indicator "AV" Constant – ECP Advanced Verification information. Specifies this record as an additional processing format of the Merchant Services standard format.

3 N Account Status Code Bank account status code response returned when a Bank Account Status Verification action was taken as part of the Advanced Verification product. Right justified/zero or blank filled Note: See Appendix X: Electronic Check Processing (ECP) for list of the Account Status Codes and descriptions that can be returned.

3 N AOA Condition Code Value returned to indicate the availability of Account Owner Authentication data. Right justified/zero or blank filled

Notes: This value is returned when Action Code = W3

See Appendix X: Electronic Check Processing (ECP) for a list of the Account Status Codes and descriptions that can be returned.

1 A Full Name Match Full name for the person match code. Valid values:

Y- Closely or exactly matches C - Conditionally (Partially) matches N - No match U - No identifying data is available " " - Blank

Notes: Indicates the results of a match on the First Name, Middle Name, and Last Name fields on the ECP Advanced Verification 1 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the First Name, Last Name, and Middle Name fields are populated on the ECP Advanced Verification 1 Format Indicator (AV01) for the transaction.




ECP Advanced Verification Reply Format Indicator (AV), (Continued)


1 A First Name Match First name match code. Valid values:

Y - Closely or exactly matches N - No match U - No identifying data is available " " - Blank

Notes: Indicates the results of a match on the First Name field on the ECP Advanced Verification 1 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the First Name field was populated on the ECP Advanced Verification 1 Format Indicator (AV01) for the transaction.

1 A Last Name Match Last name match code. Valid values:


Notes: Indicates the results of a match on the Last Name field on the ECP Advanced Verification 1 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Last Name field was populated on the ECP Advanced Verification 1 Format Indicator (AV01) for the transaction.






1 A Middle Name or Initial Match

Middle name or initial match code. Valid values:


Notes: Indicates the results of a match on Middle Name or Initial field on the ECP Advanced Verification 1 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Middle Name or Initial field was populated on the ECP Advanced Verification 1 Format Indicator (AV01) for the transaction.

1 A Business Name Match

Business name match. Valid values:


Notes: Indicates the results of a match on the Business Name field on the ECP Advanced Verification 1 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Business Name field was populated on the ECP Advanced Verification 1 Format Indicator (AV01) for the transaction.






1 A Address 1 and/or Address 2 Match

Address 1 and/or address 2 match code. Valid values:


Notes: Indicates the results of a match on the combined Address 1 and Address 2 fields on the ECP Advanced Verification 2 Format Indicator (AV02) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Address 1 and/or Address 2 fields were populated on the ECP Advanced Verification 2 Format Indicator (AV02) for the transaction.

1 A City Match City name match. Valid values:


Notes: Indicates the results of a match on City field on the ECP Advanced Verification 2 Format Indicator (AV02) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the City field was populated on the ECP Advanced Verification 2 Format Indicator (AV02) for the transaction.






1 A State Match State match code. Valid values:

Y- Closely or exactly matches N - No match U - No identifying data is available " " - Blank

Notes: Indicates the results of a match on the State field on the ECP Advanced Verification 2 Format Indicator (AV01) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the State field was populated on the ECP Advanced Verification 2 Format Indicator (AV02) for the transaction.

1 A Zip Code Match Zip code match code. Valid values:


Notes: Indicates the results of a match on the Zip field on the ECP Advanced Verification 2 Format Indicator (AV02) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Zip field was populated on the ECP Advanced Verification 2 Format Indicator (AV02) for the transaction.






1 A Phone Match Phone match code. Valid values:


Notes: Indicates the results of a match on the Phone field on the ECP Advanced Verification 2 Format Indicator (AV02) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the Phone field was populated on the ECP Advanced Verification 2 Format Indicator (AV02) for the transaction.

1 A Tax Identification Number (TIN) Match

TIN match code. Valid values:


Notes: Indicates the results of a match of the last four digits the TIN field on the ECP Advanced Verification 4 Format Indicator (AV04) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the City field was populated on the ECP Advanced Verification 4 Format Indicator (AV04) for the transaction.






1 A DOB match Date of birth match code. Valid values:


Notes: Indicates the results of a match on the DOB field on the ECP Advanced Verification 4 Format Indicator (AV04) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the DOB field was populated on the ECP Advanced Verification 4 Format Indicator (AV04) for the transaction.

1 A ID Type Match ID type match code. Valid values:


Notes: Indicates the results of a match on ID Type field on the ECP Advanced Verification 4 Format Indicator (AV04) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the ID Type field was populated on the ECP Advanced Verification 4 Format Indicator (AV04) for the transaction.






1 A ID Number Match Identification number match code. Valid values:


Notes: Indicates the results of a match on the ID Number field on the ECP Advanced Verification 4 Format Indicator (AV04) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the ID Number Match field was populated on the ECP Advanced Verification 4 Format Indicator (AV04) for the transaction.

1 A ID State Match Identification state match code. Valid values:


Notes: Indicates the results of a match on ID State field on the ECP Advanced Verification 4 Format Indicator (AV04) for an Account Owner Authentication. This value is returned when Action Code = W3, the AOA Condition Code response is 000, and the ID State field was populated on the ECP Advanced Verification 4 Format Indicator (AV04) for the transaction.

3 A Reserved Blanks





Notes: This Reply Format Indicator is only returned when Merchant Risk Assessment is enabled, Action Code =W3, and the AOA Condition Code response = 000. See Appendix X: Electronic Check Processing (ECP) for more details regarding the Advanced Verification actions and the resulting responses.

Sample 8 9 0 1 56789012345678901234567890 AV699000YYYYYYYYYYYYYYY



Bill Me Later Reply Format Indicator (BM)


2 A Format Indicator "BM" Constant – Bill Me Later information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

4 N Expiration Date Expiration date assigned by BillMeLater. (Optional)

MMYY format

12 N Credit Line Credit line assigned by BillMeLater. (Optional)


8 A Promo Offer Code for promotional offer assigned by BillMeLater. (Optional)


12 N Approved Amount Approved amount of authorization. (Optional)

Two decimals implied/right justified/zero filled

8 A Approved Term Code Indicates the approved lease or risk based pricing terms. (Optional)


1 A Shipping Address Indicator

Indicates commercial or residential shipping address. (Optional)

Valid values: A – APO/FPO C – Commercial I – International N – Non-Continental U.S. P – Post Office R – Residential




Bill Me Later Reply Format Indicator (BM), (Continued)


8 A LTV Estimator Lifetime Value Estimator. Score for merchant marketing services. (Optional)


8 A Risk Estimator Score for merchant risk services. (Optional)


8 A Risk Queue Assignment

Attribute for merchant risk services. (Optional)


10 A Lease Master Agreement ID

Lease Master Agreement ID. (Optional)


12 A Lease Documentation Requirement

String of the document codes that the lease holding company requires for this lease. (Optional)

Left justified/blank filled Note: This Reply Format Indicator is returned when Format Indicator = BM was sent on the transaction.

Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 BM1207000000900000A4 00000050000090 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 6 7 012345678901234567 AAAAAAAAAAAAAA



Balance Inquiry Reply Format Indicator (BQ)


2 A Format Indicator "BQ" Constant – Balance Inquiry information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Current Balance Current balance.


Note: This Reply Format Indicator is always returned for approved transactions when Action Code = BI and MOP = MP.

Sample 8 9 56789012345678 BQ000000005000



Bill Me Later Private Label (BML PL) Reply Format Indicator (BR)


2 A Format Indicator "BR" Constant – Bill Me Later Private Label information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

4 N Expiration Date Expiration date assigned by BillMeLater. (Optional)

MMYY format

12 N Credit Line Credit line assigned by BillMeLater. (Optional)


8 A Promo Offer Code for promotional offer assigned by BillMeLater. (Optional)

Left justified/blank filled Note: This Reply Format Indicator is returned when Format Indicator = BP was sent on the transaction.

Sample 8 9 0 1 56789012345678901234567890 BR1206000000500000ABCDEF



Balance Inquiry 2 Reply Format Indicator (BX)


2 A Format Indicator "BX" Constant – Balance Inquiry 2 information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Current Balance Current balance or open to buy balance. (Optional)

Two decimal implied/right justified/zero filled or blanks.

1 A Current Balance Sign Current balance sign. (Optional) Valid values:

N – Open to buy less than or equal to zero. P – Open to buy greater than or equal to zero. " " – Sign not available.

3 N Current Balance Currency Code

ISO currency code of the current balance. (Optional)

Note: This Reply Format Indicator is returned when Action Code = BI and MOP = CR, CZ, DD, DI, IM, MC, MR, VI, or VR.

Sample 8 9 0 567890123456789012 BX000000005000P840



Cash Back Reply Format Indicator (CO)


2 A Format Indicator "CO" Constant – Cash back information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Cash Back Amount Requested

Echoed back from Cash Back Format Indicator (CO).

12 N Cash Back Amount Approved

Amount approved to be given to the customer as cash.

Two decimal implied/right justified/zero filled Notes: This Reply Format Indicator is returned when Format Indicator = CO was sent on the transaction. This Reply Format Indicator is returned when cash back is requested in the Debit Information Format Indicator – PIN-Based Debit Only (DB).

Sample 8 9 10 11 56789012345678901234567890 CO000000002000000000002000



Card Issuing Country Status Reply Format Indicator (CS)


2 A Format Indicator "CS" Constant – Card Issuing Country Status information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

1 A Country Status Used to identify the status of the card issuing country.

Valid values: A – Acceptable B – Blocked S – Suspect

2 A Country Code The two-character standard ISO country code that identifies the card's issuing country.

Left justified/blank filled Notes: This Reply Format Indicator may be returned when the transaction division is enabled for the Issuing Country Filter.

See Appendix AC: Fraud Filters for product information.

Sample 8 56789 CSAUS



Card Type Indicator Reply Format Indicator (CT01)


4 A Format Indicator "CT01" Constant – Card Type Indicator information. Specifies this record as an additional reply processing format of the Merchant Services standard format.

3 A Country Code/ Country of Issuance

Country of issuance as indicated by the issuer.


Note: The three-character standard alpha ISO country code that identifies the card's issuing country.

1 A Durbin Regulated Indicates whether the issuing bank’s card range is regulated or not from the Durbin Amendment due to the bank assets.

Valid values: Y – Yes (assets greater than $10B – regulated) N – No (assets less than $10B – not regulated) X – Not applicable/unknown

1 A Commercial Card Indicates whether the card type is a commercial card and is capable of processing Level 2 transactions.

Valid values: Y – Yes N – No X – Not applicable/unknown

1 A Prepaid Card Indicates whether the card is a prepaid card.





Card Type Indicator Reply Format Indicator (CT01), (Continued)


1 A Payroll Card Indicates whether the card is a payroll card.


1 A Healthcare Card Indicates whether the card is a healthcare card.


1 A Affluent Category Indicates whether the card supports accountholders with higher credit limits.


1 A Signature Debit Indicates whether the card is a signature debit card.


1 A PINless Debit Indicates whether the card is PINless debit capable.






Notes: This Reply Format Indicator is returned when the Card Type Indicator Format Indicator (CT) Format Version = 01 is sent on the transaction and the transaction is approved or declined.


Sample 8 9 567890123456789 CT01USAYNNYYYNY



Card Type Indicator Reply Format Indicator (CT02)


4 A Format Indicator "CT02" Constant – Card Type Indicator information. Specifies this record as an additional reply processing format of the Merchant Services standard format.

3 A Country Code/ Country of Issuance

Country of issuance as indicated by the issuer.


Note: The three-character standard alpha ISO country code that identifies the card's issuing country.

1 A Durbin Regulated Indicates whether the issuing bank’s card range is regulated or not from the Durbin Amendment due to the bank assets.

Valid values: Y – Yes (assets greater than $10B – regulated) N – No (assets less than $10B – not regulated) X – Not applicable/unknown

1 A Commercial Card Indicates whether the card type is a commercial card and is capable of processing Level 2 transactions.


1 A Prepaid Card Indicates whether the card is a prepaid card.







1 A Payroll Card Indicates whether the card is a payroll card.


1 A Healthcare Card Indicates whether the card is a healthcare card.


1 A Affluent Category Indicates whether the card supports accountholders with higher credit limits.


1 A Signature Debit Indicates whether the card is a signature debit card.


1 A PINless Debit Indicates whether the card is PINless debit capable.







1 A Level 3 Interchange Eligible

Indicates the card as being Level 3 interchange eligible. This enables the merchant to send Level 3 transaction data to qualify for the best possible interchange rate at the time of deposit.


Note: Applies to ChaseNet, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit only.

Notes: This Reply Format Indicator is returned when the Card Type Indicator Format Indicator (CT) Format Version = 02 is sent on the transaction and the transaction is approved or declined.


Sample 8 9 567890123456789 CT01USAYNNYYYNY



Chip EMV® Reply Format Indicator (CP)


2 A Format

Indicator

"CP" Constant – Chip EMV® data information. Specifies this record as an additional processing format of the Merchant Services standard format.

3 N Size of Chip Data 3 byte ASCII header that contains the overall length of the expanded ASCII version of the binary encoded data. Maximum length allowed is 999.


1-999 A Chip Data Contains several EMV/Contactless tags represented in the BER-TLV format (single-byte ASCII).

Variable up to 999.

Left justified.

Notes: This Reply Format Indicator is returned when Action Code = AU and the Chip EMV® Data Format Indicator (CP) was sent on the transaction.

See Appendix AP: Chip EMV®.

Sample 8 9 56789 CP001



Debit Reply Format Indicator (DB)


2 A Format Indicator "DB" Constant – Debit information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Total Amount Total transaction amount, including surcharge (if any).


12 N Surcharge Amount Amount of surcharge.


Notes: Not applicable for PINless Debit.

Field is zero filled if there is no surcharge.

8 A Trace Number Trace number returned from debit vendor.

Left justified/blank filled Note: This Reply Format Indicator is returned when MOP = any Debit MOP.

Sample 8 9 0 1 5678901234567890123456789012345678 DB00000000757500000000000012345678



Digital PAN Reply Format Indicator (DN)


2 A Format Indicator "DN" Constant – Consumer Digital Payment Token information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 A Token Assurance Level

Token assurance level returned by card brands. Note: This field may be blank.

1 A Account Status Status of the token BIN. (Optional) Valid values:

N – Unregulated R – Regulated “ “ – blanks

Note: Only populated on Visa transactions.

11 A Token Requestor ID Token requestor identifier returned by card brands. (Optional)

23 A Reserved Blanks Notes: This Reply Format Indicator is returned when a Consumer Digital Payment Token is sent in the Account Number field of the Online Processing Detail Record and the transaction is approved. When MOP = DI, this Reply Format Indicator may or may not be returned.

Sample 8 9 0 1 2 567890123456789012345678901234567890123 DNA1



European Direct Debit 2 Reply Format Indicator (E2)


2 A Format Indicator "E2" Constant – European direct debit information. Specifies this record as an additional processing format of the Merchant Services standard format.

34 A IBAN Customer’s International Bank Account Number (IBAN)


11 A BIC Customer’s Bank Identifier Code (BIC).

Left justified/blank filled Notes: This Reply Format Indicator is returned when MOP = ED and an IBAN, located on the European Direct Debit 2 Format Indicator (E2), is populated.

This Reply Format Indicator is returned if the transaction division flag is enabled to return IBAN information and the transaction is not rejected.

See Appendix K: European Direct Debit for additional information on the return of this Format Indicator.

Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901 E2123456789123456789123456789123456798765432



Electronic Benefits Transfer Reply Format Indicator (EBT)


3 A Format Indicator "EBT" Constant – Electronic Benefits Transfer information. Specifies this record as an additional processing format of the Merchant Services standard format.

2 N Count Indicates the number of groups of balance types and amounts. Right justified/zero filled

Variable A Balance Type, Sign, and Amount

Balance type and amount. More than one balance type and amount may be returned. Each grouping of balance type and amount is 16 bytes. Each grouping has the following format:

BBBSAAAAAAAAAAAA where:

BBB = Balance Type Valid values:

BBL – Beginning balance CAB – Cash available balance CBB – Cash beginning balance CLB – Cash ledger balance FSA – Food stamp available balance FSL – Food stamp ledger balance

S = Amount Sign

Valid values: + – Positive Amount - – Negative Amount

AAAAAAAAAAAA = Amount

12-byte, two decimal implied/right justified/zero filled




Electronic Benefits Transfer Reply Format Indicator (EBT), (Continued)


Balance Type, Sign, and Amount, (Continued)

Examples: A positive FSA balance of $100.00:

FSA+000000010000 A negative FSA balance of $5.00:

FSA-000000000500

A negative FSL balance of $100.00 and a positive FSA balance of $100.00:

FSL-000000010000FSA+000000010000 Sample 8 0 1 2 3 5678901234567890123456789012345678901 EBT02FSL-000000010000FSA+000000010000



Gift Card Reply Format Indicator (FC)


2 A Format Indicator "FC" Constant – Gift Card information. Specifies this record as an additional processing reply format of the Merchant Services standard format.



12 N Previous Balance Previous balance prior to sale.


4 N Expiration Date Expiration date. (Optional)

MMYY format

12 N Redemption Amount Amount posted using partial redemption flag.


Note: If Partial Redemption Indicator Flag is not sent or is N on the Gift Card Format Indicator (FC), this field is zero filled.

40 A Original Reference Number

Reference number of the transaction.


Note: This Reply Format Indicator is returned when MOP = SV.

Sample 8 9 0 1 2 3 567890123456789012345678901234567890123456789012345 FC0000000010000000000020001249000000000000123456789



ACCESS FX Cross Currency Reply Format Indicator (FX)


2 A Format Indicator "FX" Constant – Access FX Specifies this record as an additional processing format of the Chase Merchant Services standard format.

1 A Opt-out indicator

If this field is populated the merchant is opting out of the special rate processing and the system is using the default currency conversion rates. Valid values:

Y = Merchant is opting out of the processing for custom IB rates. N = Default value, Merchant is opting in for the processing of custom IB rates.

Note: If the Opt-out Indicator = “Y”, then all of the subsequent fields in the record are populated with spaces.

1 A Rate Handling Indicator

Indicator to allow the merchant to determine the processing of the Rate ID. If there is an issue with the Rate ID, the transaction can either be rejected or it can use a default rate ID for Deposit processing. Valid values:

D = Default Rate ID is used if the Rate ID cannot be determined. R = Reject the transaction if the Rate ID cannot be determined.

Notes: If the Opt-out Indicator field = Y, this field can be blank. If the Opt-out Indicator field = N", this field is mandatory. If the Opt-out Indicator field is Y, but an invalid value is sent in the Rate Handling Indicator field, the transaction rejects with Response Reason Code 225 (Invalid Field Data) and has a Rate Status of “010.”




ACCESS FX Cross Currency Reply Format Indicator (FX), (Continued)


37 A Rate Identifier Rate identifier is used to indicate the rate that is being used for the transaction. Left justified/blank filled

20 N Exchange Rate Exchange Rate is populated from the Rate field in the Merchant Rate File and is used for the cross currency conversion. Include the decimal as it is sent.

Left justified//space filled

3 N Presentment Currency Presentment Currency involved in the transaction.



3 N Settlement Currency Settlement Currency involved for Settlement. Right justified/zero filled.


1 A Default Rate Indicator Indicates that the default RateID and Rate was used to process the record

Valid values: Y = Default Rate ID/Rate used for processing N = Default was not used.




ACCESS FX Cross Currency Reply Format Indicator (FX), (Continued)


3 A Rate Status This field is populated to communicate and notify the merchant of the status of the rate information exchanged with Chase Merchant Services.

Right justified, zero filled

Valid values: 000 = Valid Rate ID 001 = Invalid Rate ID 002 = Missing Rate ID 003 = Expired Rate ID 004 = Invalid ACTION code, not supported 005 = Invalid ACTION code to Rate file ACTION (for Authorization, Conditional Deposit, Deposit and Refund) 006 = Invalid Currency used 007 = Opt out selected - no custom rates applied 008 = Invalid MOP, not supported 009 = Opt out indicator invalid 010 = Rate Handling indicator invalid 011 = Rate ID and Rate mismatch 012 = Other

Sample 8 9 0 1 2 3 4 5 5678901234567890123456789012345678901234567890123456789012345678901234567 FXNDa12345678-1a2b-3cde-a123-45b6c7d89e001.23456789 840978N000



Gift Card Block Activation Reply Format Indicator (F1)


2 A Format Indicator "F1" Constant – Gift Card block activation information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

40 A Original Reference Number

Reference number of the transaction.


19 N Failed Account Number

Account number that caused failure of the transaction request.

Note: This Reply Format Indicator is returned when MOP = SV and Action Code = BA.

Sample 8 9 0 1 2 3 4 5678901234567890123456789012345678901234567890123456789012345 F1123456789 6035718888880000535



Rules Triggered Reply Format Indicator (KR)


2 A Format Indicator "KR" Constant – Fraud scoring information. Specifies this record as an additional reply processing format of the Merchant Services standard format.

3 N Data Length Indicates the number of positions returned for the following field.

Valid values: 005-999

Variable A Rules Triggered Comma-delimited list of rules triggered.

Notes: The first four positions in the list are the number of rules returned, followed by “=.”

If more rules are triggered than can fit in one record, the last character in this field is “+.”

If no rules are triggered, then "0000=" is returned.

Note: This Reply Format Indicator is returned when Returned Rules Triggered = Y located on the Fraud Scoring 1 Format Indicator (KT01) or Fraud Scoring 2 Format Indicator (KT02).

Samples

No Rules Triggered 8 9 5678901234 KR0050000=

Two Rules Triggered 8 9 0 567890123456789012345 KR0160002=rule1,rule2



Fraud Scoring 1 Reply Format Indicator (KT01)


4 A Format Indicator "KT01" Constant – Fraud detection/scoring information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

4 A Fraud Status Code A unique code indicating the fraud status of the transaction.


Note: See Appendix AE: Safetech Fraud Tools for list of valid values.

32 A Risk Inquiry Transaction ID

Unique ID used to identify the fraud assessment.


1 A Auto Decision Response

The auto decision response code. (Optional)

Valid values: A – Approve D – Decline E – Manager Review R – Review " " – Blank

2 N Risk Score The risk score returned for the transaction.

Note: This field may be blank if Safetech fraud scoring was not successful.

1 A Kaptcha Match Flag Indicates if a RIS has a corresponding Kaptcha record. (Optional)

Valid values: Y – Yes N – No " " – Blank




Fraud Scoring 1 Reply Format Indicator (KT01), (Continued)

Notes: This Reply Format Indicator is sent back when Fraud Scoring 1 Format Indicator (KT01) is sent on the transaction and the transaction is approved or declined.


Sample 8 9 0 1 2 56789012345678901234567890123456789012345678 KT01A000123456789 A78Y



Fraud Scoring 2 Reply Format Indicator (KT02)


4 A Format Indicator "KT02" Constant – Fraud detection/scoring information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

4 A Fraud Status Code A unique code indicating the fraud status of the transaction.


Note: See Appendix AE: Safetech Fraud Tools for a list of valid values.

32 A Risk Inquiry Transaction ID

Unique ID used to identify the fraud assessment.


1 A Auto Decision Response

The auto decision response code. (Optional)

Valid values: A – Approve D – Decline E – Manager Review R – Review " " – Blank

2 N Risk Score The risk score returned for the transaction.

Note: This field may be blank if Safetech fraud scoring was not successful.

2 A Worst Country The worst country associated with the customer in the last 14 days. (Optional)


Note: This is the two character country code as defined in the ISO 3166 standard.






2 A Customer Region The estimated region of the customer. (Optional)


Note: If the region is returned as lowercase, it is a state or province. If the region is returned as uppercase, it is a country.

Examples: ca = California CA = Canada

4 A Payment Brand The payment method brand identified during Safetech fraud scoring. (Optional)


Valid values: AMEX – American Express AUBC – Australian Bankcard BLML – Bill Me Later Private Label CHEK – Check CHIN – China Pay DISC – Discover DNRS – Diners Club GDMP – Green Dot/MoneyPak JCB – JCB International MSRO – Maestro MSTR – MasterCard PYPL – Paypal SOLO – Solo SWCH – Switch VISA – Visa VISE – Visa Electron UNKN – Other " " – Blanks

Note: When MOP = CR or CZ the field is populated with “VISA”.

2 A 14-Day Velocity The total number of prior sales by this customer in the last 14 days. (Optional)







2 A 6-Hour Velocity The total number of prior sales by this customer in any six hour window over the last 14 days. (Optional)


1 A Customer Network The customer network type. (Optional)

Valid values: A – Anonymous H – High School L – Library N – Normal P – Prison S – Satellite " " – Blank

3 A Number of Devices with Transaction

The number of devices associated with the transaction that the fraud system has recorded. (Optional)


3 A Number of Cards with Transaction

The number of cards associated with transaction that the fraud system has recorded. (Optional)


3 A Number of Emails with Transaction

The number of emails associated with the transaction that the fraud system has recorded. (Optional)


1 A Kaptcha Match Flag Indicates if a RIS has a corresponding Kaptcha record. (Optional)






Length Data Type

Field Name Comments

54 A Device Layers Five 10-character description values (each considered a “layer”) that identify different properties or characteristics for a specific device. Each layer is delimited by periods. (Optional)


Notes: Each layer is ten characters long and may be absent if data for that layer could not be gathered.

When progressing from layers one through five, the information becomes less precise.

The names and descriptions of the layers are explained below: Layer Number

Layer Name

Description

1 Network/OS/SSL

The Network, OS, and SSL layers return very definite information.

2 Flash The Flash layer queries the device to determine if it is Flash capable and if so, gathers device data via Flash.

3 Java Script

The JavaScript layer queries the device to determine if it is JavaScript capable and if so, gathers device data via JavaScript.

4 HTTP The HTTP layer queries HTTP headers for a number of device associated data.





Length Data Type

Field Name Comments

Device Layers, (Continued)

Notes, (Continued):

Layer Number

Layer Name

Description

5 Browser The Browser Layer queries the high-level browser to collect information about the browser such as the user-agent string and type of browser.

Example: 329B0D35C3.41111A0B4A. E25F177B32.A44B4CCB26.50C895C866

32 A Device Fingerprint A 32-character hash that represents multiple system identifiers considered to be constants on a device. (Optional)


4 N Customer Time Zone The time zone where the customer resides, which is shown as a four digit number indicating the offset in minutes from Greenwich Mean Time (GMT). (Optional)

16 N Customer Local Date/Time

Local date/time set on the device. (Optional)

YYYY-MM-DD+HH:MM format

2 A Device Region The region or state where the customer’s device resides. (Optional)


Note: If the region is returned as lowercase, it is a state or province. If the region is returned as uppercase, it is a country.

Examples: ca = California CA = Canada





Length Data Type

Field Name Comments

2 A Device Country The country where the customer’s device resides. (Optional)



1 A Proxy Status Indicates whether the device is using a proxy. (Optional)


1 A Javascript Status Indicates whether the device’s browser allows JavaScript. (Optional)


1 A Flash Status Indicates whether the device’s browser allows Flash. (Optional)


1 A Cookies Status Indicates whether the device’s browser allows cookies. (Optional)


2 A Browser Country The country where the browser resides. (Optional)








2 A Browser Language Indicates the language of the browser. (Optional)


Note: This is the two character language code as defined in the ISO 639-1 standard.

Example: EN = English

1 A Mobile Device Indicator Indicates whether the device is a mobile device. (Optional)


32 A Mobile Device Type The type of the mobile device. (Optional)


1 A Mobile Wireless Indicator

Indicates whether the device has wireless capabilities. (Optional)


1 A Voice Device Indicates whether the device is voice controlled. (Optional)


1 A PC Remote Indicator Indicates whether the device is a remotely controlled computer. (Optional)






Notes: This Reply Format Indicator is sent back when Fraud Scoring 2 Format Indicator (KT02) is sent on the transaction and is approved or declined.


Sample 8 9 0 1 2 3 4 5 6 7 56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 KT02A000123456789 A78 VISA A002002025Y329B0D35C3.41111A0B4A.E25F177

8 9 0 1 2 3 4 5 6 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 B32.A44B4CCB26.50C895C866 2011-03-11 09:22ca

7 8 9 0 01234567890123456789012345678901234



Merchant Echo Reply Format Indicator (ME)


2 A Format Indicator "ME" Constant – Merchant echo information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

2 N Length Indicator Echoed back from Merchant Echo Format Indicator (ME).

Variable 1-99

A Merchant Echo Field Echoed back from Merchant Echo Format Indicator (ME).

Note: This Reply Format Indicator is returned when Merchant Echo Format Indicator (ME) is sent on the transaction.

Sample 8 9 0 1 56789012345678901234567890 ME22MERCHANT SUPPLIED INFO



MoneyPak Reply Format Indicator (MP)


2 A Format Indicator "MP" Constant – MoneyPak information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

20 A Original Transaction ID Verifies acceptance of the MoneyPak transaction.


Note: This value is used on subsequent transactions when Action Code = DP, RA, or RF.

25 A Confirmation ID Confirms the balance of the MoneyPak card has been changed.


Note: This value is used on subsequent transactions when Action Code = DP, RA, or RF.

20 N MoneyPak Account Number

Echoed back from MoneyPak Format Indicator (MP).

Note: This Reply Format Indicator is always returned for approved transactions when MOP = MP and Action Code = PA or RA, or when the MoneyPak Account Number is sent on input.

Sample 8 9 0 1 2 3 4 5 5678901234567890123456789012345678901234567890123456789012345678901 MP77777777778888888888123456789012345678901234598765432100123456789



Message Type Records Reply Format Indicator (MT)


2 A Format Indicator "MT" Constant – Message Type Records information.

Specifies this record as an additional processing reply format of the Merchant Services standard format.

4 A Message Type

Indicates the message type to be used for the message type records.

Echoed back from the Message Type Records Format Indicator (MT).

1 A Stored Credential Flag Indicates that the customer’s credentials are on-file with the merchant.


15 A Submitted Transaction ID

The Submitted Transaction ID (TXID) returned to the merchant from a previous authorization request in a series of transactions.


15 A Response Transaction ID

Response Transaction ID (TXID) – this is returned to the merchant and is output-only.


12 A Filler Reserved (for future use) Note: This Reply Format Indicator is returned for all Message Type Record (MT).

Message Type Examples Sample for MUSE 8 9 0 1 2 567890123456789012345678901234567890123456789 MTMUSEY123456789876543



Partial Authorization Reply Format Indicator (PB)


2 A Format Indicator "PB" Constant – Partial authorization information. Specifies this record as an additional processing reply format of the Merchant Services standard format.


Two decimal implied/right justified/zero filled or blanks Notes: American Express may return the current balance.

Discover and Discover Diners may return the current balance.

ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit may return the current balance.

MoneyPak and PIN-Based Debit do not return the current balance.

12 N Redemption Amount Approved partial redemption amount.


Notes: If the Partial Redemption Indicator Flag = N, this field is zero filled.

When MCC = 5542 and partial authorizations are enabled, this field can be greater than the amount of the transaction.

Notes: This Reply Format Indicator could be returned for any partial authorization capable transaction (i.e. via transaction division default or Partial Redemption Indicator Flag).

See Appendix G: Partial Authorization for specific information on when this Reply Format Indicator is returned.

Sample 8 9 0 1 56789012345678901234567890 PB000000000999000000000999



Personal Information 2 Reply Format Indicator (P2)


2 A Format Indicator "P2" Constant –Personal information 2. Specifies this record as an additional processing reply format of the Merchant Services standard format.

25 A Payer ID Customer account number.


1 A Email Address Status Indicates if the payer’s email address (i.e. account) was verified.


1 A Address Status Indicates if the payer’s ship to address was verified.


Notes: This Reply Format Indicator is returned when MOP = PY, Action Code = EG, and Response Reason Code = 100 (Approved).


Sample 8 9 0 1 56789012345678901234567890123 P2FYA122PZY387 YN



Response Information Reply Format Indicator (RI)


2 A Format Indicator "RI" Constant – Response information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

2 A AVS Response Code Response for the Address Verification request.


Notes: When MOP does not equal AX and the Enhanced Verification Flag = Y, located on the Request Information Format Indicator (RI), this field is populated as well as the AVS Response Code field in the Online Processing Return Format Record.

When MOP = AX, and the Enhanced Verification Flag = Y, this field is blank.

When MOP = AX, and the Enhanced Verification Flag = Y, but the inbound address information does not pass Merchant Services edit checks, this field may be populated as well as the AVS Response Code field in the Online Processing Return Format Record.

If this field is populated, the AVS Response Code field on the Online Processing Return Format Record is also populated.

This field is currently only populated for American Express transactions.

1 A Postal Code Verification Response

The Bill to Postal Code verification response.

Valid values: N – Data does not match R – Retry S – Service not allowed U – Data unchecked Y – Data matches " " – Blank (Data not sent)

Note: This field is currently only populated for American Express transactions.




Response Information Reply Format Indicator (RI), (Continued)


1 A Street Verification Response

The Bill to Street Address verification response.



1 A Name Verification Response

The Bill to Name verification response.

Valid values for American Express: N – Data does not match R – Retry S – Service not allowed U – Data unchecked Y – Data matches " " – Blank (Data not sent)

Valid values for Discover, Discover Diners, and JCB:

B – No name given with transaction F – First name matches, last name does not K – Unknown L – Last name matches, first name does not M – First and last names both match N – Data does not match P – Not processed W – Data not sent U – Retry

1 A Phone Verification Response

The Bill to Phone verification response.






Response Information Reply Format Indicator (RI), (Continued)


1 A Email Verification Response

The Bill to Email verification response.



3 A Reserved Blanks Notes: This Reply Format Indicator is returned when the Enhanced Verification Flag, located on the Request Information Format Indicator (RI) = Y. See Appendix B: Address Verification.

8 9 567890123456 RI YUSRN



Response Message Reply Format Indicator (RM)


2 A Format Indicator "RM" Constant –Response message information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

2 N Length Indicator Indicates the number of positions returned for the following field:

Valid values: 01 –90

Variable 1-90

A Message Text Response message text.

Left justified/blank filled Notes: This Reply Format Indicator is returned when MOP = PY, except when there is a front end reject or Response Reason Code = 000 (No Answer) or 100 (Approved). This Reply Format Indicator may be returned when the Bill Me Later Information Format Indicator (BM) was sent on the transaction.

Sample 8 9 0 1 567890123456789012345678901 RM23SAMPLE RESPONSE MESSAGE



Shop with Points Information Reply Format Indicator (SI)


2 A Format Indicator "SI" Constant – Shop with Points information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Rewards Transaction Amount

The number of rewards being redeemed for this transaction.


5 A Rewards Currency Unit of Measure of the rewards being redeemed.

Left justified/blank filled Valid values:


12 A Shop with Points Trace Number

Unique trace number (echoed back from Order Information 6 (O6) Format Indicator).

Left justified/blank filled Note: This Reply Format Indicator is returned when MOP = C9 and Action Code = AU or AR and Response Reason Code = 100 (Approved).

Sample 8 9 0 1 5678901234567890123456789012345 SI000000312500WPTS



Shop with Points Reply Format Indicator (SP)


2 A Format Indicator "SP" Constant – Shop with Points information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

12 N Rewards Balance The number of rewards available for this account.


12 N Converted Rewards Balance

The U.S. Dollar cash equivalent of the rewards balance.


5 A Rewards Currency Unit of measure of the rewards being redeemed.

Left justified/blank filled Valid values:


10 N Conversion Rate The value used to convert U.S. Dollars to rewards.


10 N Minimum Spend The minimum U.S. Dollars spend amount.


Note: This field may be blank depending on merchant reward program setup.




Shop with Points Reply Format Indicator (SP), (Continued)


10 N Maximum Spend The maximum U.S. Dollars spend amount.


Note: This field may be blank depending on merchant reward program setup.

4 A Product Code Code assigned to the rewards program.


10 A Content ID Determines the additional messaging a merchant displays, including the Terms & Conditions.

Left justified/blank filled Note: This Reply Format Indicator is returned when MOP = C9 and Action Code = BI, ET, or HC.

Sample 8 9 0 1 2 3 4 5 567890123456789012345678901234567890123456789012345678901234567890123456789 SP000000312500000000002500WPTS 00000001250000000100099999999904410441



Token ID Reply Format Indicator (TI)


2 A Format Indicator "TI" Constant –Token ID information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

20 A Token ID Time stamped token.


Notes: This Reply Format Indicator may be returned when the Encryption Flag, located on the Online Processing Detail Record, is populated with 201, 202, 203, or 204.

When Encryption Flag = 201 or 202, located on the Online Processing Detail Record, this Reply Format Indicator is not returned if Merchant Services is unable to provide a token. The transaction rejects with Response Reason Code = 281 (Token Unavailable).

When Encryption Flag = 203 and Action Code = TN, located on the Online Processing Detail Record, this Reply Format Indicator is not returned if Merchant Services is unable to provide a token. The transaction rejects with Response Reason Code = 281 (Token Unavailable).

When Encryption Flag = 203, located on the Online Processing Detail Record, this Reply Format Indicator is not returned if Merchant Services is unable to provide a token. If the transaction is approved (Response Reason Code = 100 (Approved)), a new request using Action Code = TN should be sent to tokenize the account number.

When Encryption Flag = 204, located on the Online Processing Detail Record, the Token ID value is the same as sent in the Account Number field, located on the Online Processing Detail Record. If the Transaction Division Safetech attributes are changed, the Token ID is a different value.


This Reply Format Indicator is always returned when MOP = PY, Action Code = ED, EG, or ES and Response Reason Code = 100 (Approved).


Sample 8 9 0 5678901234567890123456 TI194829A12375B192384



Transaction ID Reply Format Indicator (TX)


2 A Format Indicator "TX" Constant –Transaction ID information. Specifies this record as an additional processing reply format of the Merchant Services standard format.

19 A Transaction ID PayPal generated transaction ID.


Note: See Appendix S: PayPal for product information.

Sample 8 9 0 567890123456789012345 TX4829012375019238479



Visa Transaction Identifier Reply Format Indicator (VI)


2 A Format Indicator "VI" Constant – Visa Transaction Identifier information. Specifies this record as an additional processing format of the Merchant Services standard format.

12 N Authorized Amount Amount of the original authorized transaction. 4 N Merchant Category

Code (MCC) Merchant category code used for the authorization.

2 N POS Entry Mode Indicates how the transaction was entered. 2 N Authorization Response

Code The authorization response from the Visa authorization system.

1 A Authorization Characteristic Indicator

Indicates PS2000 characteristics.

15 N Transaction Identifier (TID)

Assigned by the Visa authorization system. An identifier, assigned by Visa, used to uniquely identify and link all related messages and records used to authorize and settle the transaction through Visa.

4 A Validation Code Assigned by the Visa authorization system. A code calculated by Visa, utilized to determine the accuracy of the authorization data contained in the settlement record.

1 A Market Specific Data Indicator

The value used for the authorization.

2 A Card Level Result Card Level Result assigned by Visa. Field is used to identify card product at the transaction level.

2 A AVS Response Code The result of the AVS request (Visa specific value).

Notes: This Reply Format Indicator is returned on all Chase Pay POS authorization transactions.

See Appendix AN: Chase Pay for more information. Sample 8 9 0 1 2 3 56789012345678901234567890123456789012345678901 VI00000007680058120345X000001234500000ABYZABAYA


FORMAT USAGE Sample Record Layouts

Below are sample Record Layouts and the corresponding Response Record Layouts for the following processing scenarios:

1. Input record layout example for Visa, with Bill to Address & Fraud (e.g. CVV2): 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF VI4123456789012345 120600001234560000000075758407 AU ABW60

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 38968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD.

18 19 20 21 22 23 0123456789012345678901234567890123456789012345678901 USSALEM NH03079 FR1321 ↵

1. Return record layout example for Bill to Address & Fraud (e.g. CVV2): 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4M4123456789012345 1206VI 000000007575↵

2. Input record layout example for AMEX, with Zip Only Address & Fraud (e.g. CID): 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF AX371234567890123 120600001234560000000075758401 AU AZ030

9 10 01234567890123456 79 USFR 9876↵

2. Return record layout example for AMEX, with Zip Only Address & Fraud (e.g. CID): 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4 371234567890123 1206AX 000000007575↵



FORMAT USAGE, (Continued)

Sample Record Layouts, (Continued)

Continued below are sample Record Layouts and the corresponding Response Record Layouts.

3. Input record layout example with Bill to Address, Employer Address, IP Address, Email Address, Ship to Address, Bill Me Later, Order Information, and Personal Information (these fields are required for the Bill Me Later product): 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF BL5049900000000000 00001234560000000075758407 AU ABH60 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 38968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD. 18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 USSALEM NH03079 AEW6038968000 JOHN D.*SMITH 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 4 NORTHEASTERN BLVD USSALEM NH03079 36 37 38 39 40 41 42 43 44 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 AIB12.9.1.2 [email protected] 45 46 47 48 49 50 51 52 53 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 ASW6038968000 JOHN D. *SMITH 54 55 56 57 58 59 60 61 62 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 USSALEM NH03079 BL000007825432120030930N 54 63 64 65 66 67 68 69 70 71 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345 32 NNNNOIPHYFEN030930153000PI197510120000012348400005000000X1 5 YY↵

3. Return record layout example for Bill to Address, Ship to Address, Employer Address, Bill Me Later, Personal Information, IP Address, Email Address, and Order Information (these fields are required for the Bill Me Later product): 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T7VABC123456789DEF 100040930654321I4 5049901234567890 BL 000000007575↵






4. Input record layout example with Gift Card Balance Inquiry and Fraud (e.g. CVD): 1 2 3 4 5 6 7 8 9 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012 P74VABC123456789DEF SV6035718888880000535124900001234560000000000008401 BI FR 4321↵

4. Return record layout example for Gift Card Balance Inquiry and Fraud (e.g. CVD): 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 M60357188888800005351249SV 000000000000FC0000000030000

10 11 12 13 14 15 16 01234567890123456789012345678901234567890123456789012345678901234567 000000030001249000000000000941111122222333 ↵

5. Input record layout example with Electronic Check with Bill to Address: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF EC0888271156 00001234560000000075758401 LO EC012

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 345678 ABH6038968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD

18 19 20 21 22 23 012345678901234567890123456789012345678901234567890123456 USSALEM NH03079 ↵

5. Return record layout example for Electronic Check with Bill to Address: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 101040930123456 0888271156 EC 000000007575↵






6. Input record layout example with Bill to Address and People’s Bank Encrypted Account Number: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF ENabc123def456ghi7 120600001234560000000075758407010 AU ABW60

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 38968000 JOHN D *SMITH 4 NORTHEASTERN BLVD

18 19 20 21 22 012345678901234567890123456789012345678901234 USSALEM NH03079 ↵

6. Return record layout example for Bill to Address and People’s Bank Encrypted Account Numbers: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4 abc123def456ghi7 1206VI 000000007575↵






7. Input record layout example with Retail Magnetic Stripe Read – Track 1: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 P74VABC123456789DEF VI4123456789012345 12060000123456000000007575840R AU RE2901

10 11 12 13 14 15 16 12345678901234567890123456789012345678901234567890123456789012345678901234567 12345^SMITH /JOHN ^0612 CVV ↵

7. Return record layout example for Retail Magnetic Stripe Read – Track 1: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4 4123456789012345 1206VI 000000007575↵

8. Input record layout example with Retail Magnetic Stripe Read – Track 2: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 P74VABC123456789DEF VI4123456789012345 12060000123456000000007575840R AU RE2902

10 11 12 13 1234567890123456789012345678901234567890 4123456789012345=0612 ↵

8. Return record layout example for Retail Magnetic Stripe Read – Track 2: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4 4123456789012345 1206VI 000000007575↵






9. Input record layout example with Retail Input for Manually Keyed with Zip: (Can be sent for all card types, but should be sent for Visa.)

1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF VI4123456789012345 12060000123456000000007575840R AU AZ03079 US↵

9. Return record layout example for Retail Input for Manually Keyed with Zip: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4 4123456789012345 1206VI 000000007575↵

10. Input record layout example with Retail Manually Keyed without AVS (all other card types). Visa requires zip code, at a minimum, to qualify for the best manually keyed rate. All other card types do not. 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 P74VABC123456789DEF MC5123456789012345 12060000123456000000007575840R AU ↵

10. Return record layout example for Retail Manually Keyed without AVS (all other card types): 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321 5123456789012345 1206MC 000000007575↵






11. Input record layout example for Discover with Bill to Address and Fraud (e.g. CID): 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF DI6011123456789012 120600001234560000000075758401 AU ABH60

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 38968000 JOHN D. *SMITH 4 NORTHEASTERN BLVD.

18 19 20 21 22 23 0123456789012345678901234567890123456789012345678901 USSALEM NH03079 FR1654 ↵

11. Return record layout example for Discover with Bill to Address and Fraud (e.g. CID): 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 T74VABC123456789DEF 100040930654321I4M6011123456789012 1206DI 000000007575↵

12. Input record layout example for PINless Debit: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF DP4543210987654321 0000123456000000007575840I PA O2BIL

9 10 11 01234567890123456789012 LREFNUM123 ↵

12. Return record layout example for PINless Debit: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 4543210987654321 SP 000000007575DB0000000075750

10 11 01234567890123456789 0000000000012345678↵





13. Input record layout example with Gift Card Authorization: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 P74VABC123456789DEF SV6035718888880000535124900001234560000000020008401 AU ↵

13. Return record layout example for Gift Card Authorization: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 60357188888800005351249SV 000000002000FC0000000030000

9 10 11 12 13 14 15 16 012345678901234567890123456789012345678901234567890123456789012345678901234567 000000050001249000000002000941112223334445 ↵

14. Input record layout example with Gift Card Redemption Complete: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 P74VABC123456789DEF SV6035718888880000535124900001234560000000020008401 RC ↵

14. Return record layout example for Gift Card Redemption Complete: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 60357188888800005351249SV 000000002000FC0000000030000

9 10 11 12 13 14 15 16 012345678901234567890123456789012345678901234567890123456789012345678901234567 000000030001249000000002000941112223334445 ↵





15. Input record layout example with Gift Card De-activation 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 P74VABC123456789DEF SV6035718888880000535124900001234560000000000008401 SD ↵

15. Return record layout example for Gift Card De-activation: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 60357188888800005351249SV 000000000000FC0000000000000

9 10 11 12 13 14 15 16 012345678901234567890123456789012345678901234567890123456789012345678901234567 000000050001249000000000000949998887776666 ↵

16. Input record layout example with Gift Card De-activation Reversal: 1 2 3 4 5 6 7 8 9 10 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123 P74VABC123456789DEF SV6035718888880000535124900001234560000000050008401 DV RV15949998887776666↵

16. Return record layout example for Gift Card De-activation Reversal: 1 2 3 4 5 6 7 8 9 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100040930654321 60357188888800005351249SV 000000005000FC0000000050000

9 10 11 12 13 14 15 16 012345678901234567890123456789012345678901234567890123456789012345678901234567 000000000001249000000000000949998887776666 ↵


APPENDIX A: RESPONSE REASON CODE DESCRIPTION/USAGE Merchant Services Response Reason Codes

The following list reflects all currently defined Merchant Services response reason codes. Many of these codes are never returned in your output.

For the most common codes returned by Merchant Services, the list includes an action field that suggests the best probable course of action to take based on the code returned. If you are receiving codes not listed here, please contact your Account Manager. For ECP transactions, please refer to the Electronic Check Processing User Guide for additional information including return codes, dishonor codes and response actions.

The following KEY describes the Column Headings and the values appearing in the columns.

Note: Not all codes are received on an authorization. Some codes are for deposit/conditionals only.

KEY Column Heading Description

Type S = Successful Response Codes R = Reject Response Codes D = Decline Response Codes

Code 3-digit response code Name Description of the response code Action Resend = Send this transaction back at any time

Wait = Wait 2-3 days before sending back, or try to resolve with your customer

Cust. = Try to resolve with customer, or get an alternate method of payment

Fix = There is an invalid field being sent. Fix and resend N/A = Not applicable Voice = Perform a voice authorization per Merchant

Services instructions Call = Call Merchant Services

Payment Method

BML = Bill Me Later Cards/Bill Me Later Private Label BML PL = Bill Me Later Private Label only CC = All Credit Cards DB = All Debit Cards ECP = Electronic Check Processing ED = European Direct Debit MP = MoneyPak PY = PayPal SV = Gift Card SwP = Shop with Points



APPENDIX A: RESPONSE REASON CODE DESCRIPTION/USAGE, (Continued)

Response Type Code Name Action

Payment Method Comments

D 000 No Answer Resend BML, CC, ED, MP, PY,

SV

Merchant Services received no answer from auth network.

S 100 Approved N/A All Successfully approved. S 101 Validated N/A ECP,

ED Account passed Merchant Services negative file and data edit check.

S 102 Validated N/A ECP Account passed Merchant Services negative file and data edit check.

S 103 Pre-noted N/A ECP Passed pre-note. S 104 Successful

Action Requested

N/A All Successful transaction.

Safetech – Returned for FA (Fraud Analysis) action.

S 106 Provided Auth N/A CC Successfully approved.

Note: Indicates customized code was used in processing.

S 107 Request Received

N/A CC Successfully approved.


S 108 Approved for Activation

N/A CC Successfully activated.


S 109 Previously Processed Transaction

N/A DB Transaction was not re-authorized with the Debit Network because it was previously processed.

S 110 BIN Alert N/A CC Successfully approved.


S 111 Approved for Partial

N/A CC Successfully approved.


S 116 Accept N/A EC ECP - Advanced Verification–Account Status Verification and/or Account Owner Authentication data is in a positive status.

S 164 Conditional Approval

Wait BML Conditional Approval - Hold shipping for 24 hours.

R 201 Invalid Account Number

Cust. All Bad check digit, length, or other credit card problem.



Response

Type Code Name Action Payment Method Comments

R 202 Bad Amount Non-numeric Amount

Fix All Amount sent was zero, unreadable, or exceeds maximum allowable amount.

R 203 Zero Amount Fix CC, ECP

Amount sent was zero.

R 204 Other Error Fix All Unidentifiable error. R 205 Bad Total

Auth Amount Fix CC The sum of the authorization amount

from extended data information does not equal detail record authorization amount.

Amount sent was zero, unreadable, over ceiling limit, or exceeds maximum allowable amount.

R 218 Invalid SKU Number

Fix CC Non-numeric value was sent.

R 219 Invalid Credit Plan


R 220 Invalid Store Number


R 225 Invalid Field Data

Fix CC, DB, ED, MP,

PY

Data within transaction is incorrect.

R 227 Missing Companion Data

Fix BML, CC, ED,

PY

Specific and relevant data within transaction is absent.

R 231 Invalid Transaction Division Number

Fix All Transaction Division number incorrect.

R 233 Does Not Match MOP

Fix CC, SwP

Credit card number does not match method of payment type or invalid BIN.

R 234 Duplicate Order Number

Fix CC Unique to authorization recycle transactions. Order number already exists in system.

Note: Auth Recycle only.

R 236 Auth Recycle Host System Down

Resend CC Authorization recycle host system temporarily unavailable.

Note: Auth Recycle only.






R 238 Invalid Currency

Fix All Currency does not match Merchant Services merchant setup for transaction division.

R 239 Invalid MOP for Transaction Division

Fix All Method of payment is invalid for the transaction division.

R 241 Illegal Action

Fix All Invalid action attempted.

R 243 Invalid Purchase Level III

Fix CC Data is inaccurate or missing, or the BIN is ineligible for P-card.

R 244 Invalid Encryption Format

Fix CC, ECP Invalid encryption flag. Data is inaccurate.

R 245 Missing or Invalid Secure Payment Data

Fix CC For Verified by Visa, ChaseNet, International Maestro, MasterCard, or Visa authentication data not in appropriate Base 64 encoding format or data provided on a non-e-Commerce transaction. For Chase Pay, data not in appropriate format.

R 246 Merchant Not MasterCard SecureCode Enabled

Call CC Transaction division does not participate in International Maestro SecureCode or MasterCard SecureCode.

R 247 Check Conversion Data Error

Fix ECP Proper data elements were not sent for POP/ARC transactions.

R 248 Blanks Not Passed in Reserved Field

Fix All Blanks not passed in Reserved Field.

R 249 Invalid MCC Fix All Invalid Merchant Category Code (MCC) sent.

R 253 Invalid Transaction Type

Fix All Invalid transaction type for this order. Note: If a European merchant is participating in Maestro Recurring Payment Program (MRPP), the AAV provided must be a static AAV, and the Transaction Type must = 2.






R 257 Missing Customer Service Phone

Fix CC Customer Service Phone Number required on Transaction Types 1 (MOTO) and 2 (Recurring).

Note: International Maestro and MasterCard Only.

R 258 Not Authorized to Send Record

Fix All Transaction division is not authorized to send record or the account is a Visa Canadian debit card.

D 260 Soft AVS Cust. CC Card was authorized, but AVS did not match. The 100 was overwritten with a 260 per the merchant’s request.

Note: Conditional deposits only. R 261 Account Not

Eligible for Transaction Division’s Setup

N/A CC Account number not eligible for transaction division’s Account Updater Program setup.

R 262 Authorization Code/ Response Date Invalid

Fix CC Authorization code and/or response date are invalid.

Note: MOP = CR, CZ, MC, MR, VI, and VR only

R 263 Partial Authorization Not Allowed or Partial Authorization Request Not Valid

Fix CC Action code or transaction division does not allow partial authorizations or partial authorization request is not valid.

R 264 Duplicate Deposit Transaction

N/A DB Transaction is a duplicate of a previously deposited transaction. Transaction is not processed.

R 265 Missing QHP Amount

Fix CC, DB Missing QHP amount.

R 266 Invalid QHP Amount

Fix CC, DB QHP amount greater than transaction amount.

R 267 Merchant Not IIAS Enabled

Call CC, DB Transaction division does not participate in Healthcare IIAS. Contact your Merchant Services Representative for information on getting setup for Healthcare IIAS.






R 268 Invalid Cash Back Amount

Fix CC Cash back amount is not less than transaction amount.

R 269 Card Prefix on Fraud Filter List

Cust. CC Card number prefix is on a fraud filter list.

Note: MOP = AX, CR, CZ, IM, MC, MR, VI, and VR.

R 270 Card Number on Fraud Filter List

Cust. CC Card number is on a fraud filter list.

R 271 Country on Fraud Filter List

Cust. CC Issuing country of the card is on a fraud filter list.

R 273 Cash Over Not Allowed on MCC

Fix CC Cash Over cannot be processed under this MCC.

Note: MOP = DD, DI, and MC only R 275 Ceiling Limit Fix All The transaction amount exceeds the

transaction division amount limit (ceiling limit) as established by the merchant's setup instructions.

R 278 Batch has no balance

Fix All Internal Merchant Services code.

Note: Merchants should not receive this code

R 279 Invalid MT Record Format

Fix CC The Message Type Record was sent in an incorrect format.

Note: ChaseNet and Visa only. R 280 Invalid

Subscriber ID Fix CC, DB,

SV Subscriber ID does not match Merchant Service’s merchant Transaction Division setup. Note: Safetech Page Encryption or Tokenization only.

R 281 Token Unavailable

Resend CC, DB, SV

Merchant Services is unable to provide a token.

Notes: A Token will not be returned.

Safetech Page Encryption or Tokenization only.

R 282 Decryption Failure

Fix CC, DB, SV

Merchant Services is unable to decrypt account number. Note: Safetech Page Encryption or Tokenization only.






R 283 Invalid Action for Encryption Type

Fix CC, DB, SV

Action Code is not supported. Note: Safetech Page Encryption or Tokenization only.

R 284 Invalid MOP for Encryption Type

Fix CC, DB, SV

MOP is not supported. Note: Safetech Page Encryption or Tokenization only.

R 285 Customer Exclusive Data

Fix CC Customer Exclusive Data (CED) EMV tag 97FC is missing.

R 295 Source of Funds Invalid

Fix CC Prepaid invalid for this transaction.

D 301 Issuer Unavailable

Resend CC, DB, ED, SV,

SwP

Authorization network could not reach the bank which issued the card.

D 302 Credit Floor Cust. BML, CC, SV

Insufficient funds.

D 303 Processor Decline

Cust. CC, MP, DB, ED, PY, SV

Generic decline – No other information is being provided by the Issuer.

D 304 Not On File Cust. BML, CC, DB, PY, SV,

SwP

No card record, or invalid/non-existent to account specified. DB – Bin not debit capable. PY – Billing agreement ID or transaction ID not valid.

R/D 305 Already Reversed/ Nothing to Reverse

N/A CC, DB Transaction previously reversed.

Debit – Transaction previously reversed or purchase authorization is older than 90 minutes or there is no authorization to reverse.

Note: MOP = any Debit MOP, CR, CZ, DD, DI, IM, MC, MR, VI, and VR only.

R 306 Amount Mis-match

Fix CC Requested reversal amount does not match original approved authorization amount.

Note: MOP = CR, CZ, DD, DI, IM, MC, MR, VI, and VR only.

R 307 Authorization Not Found

Fix CC Transaction cannot be matched to an authorization that was stored in the database.

Note: MOP = CR, CZ, DD, DI, IM, MC, MR, VI, and VR only.




Response


D 401 Call Voice CC, DB, SwP

Issuer wants voice contact with accountholder.

D 401 Decline Cust. BML Decline D 402 Default Call Voice CC Decline D 452 Account

Already Redeemed

Cust. MP Account has no available funds.

D 456 Invalid Refund Amount

Cust. MP Refund amount does not match deposit amount.

D 457 Verification Denied

Cust. MP Generic Decline - No other information is being provided by the issuer.

D 458 Verification Error

Cust. MP Generic Decline - No other information is being provided by the issuer.

D 461 Account Is Not Redeemed

Cust. MP Account has not been activated.

D 465 Account Already Refunded

Cust. MP Amount already refunded.

D 468 Number of Agreements Exceeded

Cust PY Maximum number of agreements was exceeded.

D 469 More Than One Agreement

Cust PY More than one agreement specified for reference transaction.

D 470 Agreement Types Cannot be Mixed

Cust PY Agreement types cannot be mixed in the same project.

D 471 Invalid Agreement Type

Cust PY Invalid agreement type.

D 472 Buyer Did Not Accept Agreement

Cust PY Buyer did not accept agreement.

D 473 Agreement for Transaction Already Created

Cust PY An agreement for the transaction has already been created. Token has already been used to create a billing agreement.




Response


D 474 Billing Address Does Not Exist

Cust PY Billing address request does not exist for the merchant.

D 501 Pickup Cust. BML, CC, DB

Card Issuer wants card returned.

D 502 Lost/Stolen Cust. CC, DB, SV

Card reported as lost/stolen.

Note: Does not apply to American Express.

D 503 Fraud/ Security Violation

Cust. CC CID did not match.

Note: Discover, Discover Diners, and JCB only

D 505 Negative File

Cust. BML On negative file.

D 508 Excessive PIN Try

Cust. CC Allowable number of PIN tries exceeded.

D 509 Over Limit Cust. BML, CC, PY, SV

Exceeds withdrawal or activity amount limit.

D 510 Over Frequency Limit

Cust. CC, SV Exceeds withdrawal or activity count limit.

D 519 On Negative File

Cust. ECP Account number appears on negative file.

Note: See the ECP Users Guide for Fair Credit Reporting (FCRA) compliance requirements.

D 521 Insufficient Funds

Cust. BML PL, PY, CC, SV, SwP

Insufficient funds/over credit limit.

D 522 Card is Expired

Cust. CC, DB, SV

Card has expired.

D 523 Encryption Data Bad

Fix DB Encryption data is bad.

D 524 Altered Data Fix BML, DB Altered Data\Magnetic stripe incorrect.






D 530 Do Not Honor

Cust. BML, CC, DB, ED, PY.

SwP

Generic decline – No other information is being provided by the Issuer.

Notes: This is a hard decline for Bill Me Later (never passes with recycle attempts). SwP - Hard decline

D 531 CVV2/VAK Failure

Cust. BML, CC

Issuer has declined auth request because CVV2 or VAK failed.

D 534 Do Not Honor – High Fraud

Cust. PY The transaction failed PayPal’s risk models.

D 540 Under 18 Years Old

Cust. BML The date of birth indicates customer is less than 18 years of age.

D 541 Possible Compromise

Cust. BML Customer reported possible compromise and blocked account.

D 542 Bill To Not Equal To Ship To

Cust. BML Bill to address does not match ship to address.

D 543 Invalid Pre-approval Number

Cust. BML Pre-approval number not recognized.

D 544 Invalid Email Address

Cust. BML Email address failed standard validation rules.

D 545 PA ITA Number Inactive

Cust. BML Pre-approval number no longer valid.

D 546 Blocked Account

Cust. BML Billing system account status.

D 547 Address Verification Failed

Fix BML Billing address could not be verified.

D 548 Not on Credit Bureau

Cust. BML Need more information. Request full social security number.

D 549 Previously Declined

Cust. BML Customer previously declined.

D 550 Closed Account, New Account Issued

Cust. BML Closed Account. New Account Issued.






D 551 Duplicate Transaction

Fix BML, CR, CZ, ED, PY, SwP, VI,

VR

Trans ID in combination with merchant ID is not unique (order number not unique).

PY – the transaction was previously processed.

CR, CZ, VI, and VR – the transaction is identified by ChaseNet or Visa as a duplicate authorization.

D 560 Re-authorization

Fix BML Re-authorization request is declined. Original authorization could not be found.

D 561 Re-authorization No Match

Fix BML Re-authorization request is declined. The customer account number, merchant id, or amount did not match the original authorization.

D 562 Re-authorization Amount Exceeded

Fix BML Re-authorization request is declined. The amount significantly exceeds the original request amount.

D 563 Re-authorization- Timeframes Exceeded

Fix BML Re-authorization request is declined. The timeframes for re-authorization have been exceeded.

D 564 Counter Offer Cust. BML Counter Offer to Supply Personal Guaranty.

D 567 Pending review Wait BML Pending review by BillMeLater wait 24 hours.

D 570 Stop Payment Order One Time Recurring / Installment

Cust. CC Accountholder has requested this one recurring/installment payment be stopped.

D 571 Revocation of Authorization for All Recurring / Installments

Cust. CC Accountholder has requested all recurring/installment payments be stopped.

D 572 Revocation of All Authorizations – Closed Account

Cust. CC Accountholder has requested that all authorizations be stopped for this account due to closed account.

Note: ChaseNet and Visa only. D 575 ECP Account

Verification/ AOA Decline

Cust EC ECP - Advanced Verification – Account Status Verification and/or Account Owner Authentication data is in a negative status.






D 576 No Information Found

Cust EC ECP - Advanced Verification – Account Status Verification did not pass the Advanced Verification lookup. The account may be brand new and no activity can be found or the account may be fraudulent. Confirm bank account with customer and possibly try again.

D 578 ECP Account Verification Decline

Cust EC ECP - Advanced Verification – Account Status Verification returned a negative status.

D 579 Not ACH Eligible

Cust EC ECP - Advanced Verification – Account is not eligible for ACH transactions and should be returned to Customer for another method of payment.

D 580 Account Previously Activated

N/A SV Account previously activated.

D 581 Unable to Void N/A SV Unable to void. D 582 Block Activation

Failed Fix SV Block activation failed – card range

not setup for MOD 10. D 583 Block Activation

Failed Fix SV Block activation failed – email or

fulfillment flags were set to ‘Y’. D 584 Issuance Does

Not Meet Minimum Amount

Fix SV Issuance does not meet minimum amount.

D 585 No Original Authorization Found

N/A SV No original authorization found.

D 586 Outstanding Authorization, Funds on Hold

N/A SV Outstanding authorization, funds on hold.

D 587 Activation Amount Incorrect

Fix SV Activation amount incorrect.

D 588 Block Activation Failed

Fix SV Block activation failed – account not correct or block size not correct.

D 589 CVD Value Failure

Cust. SV Magnetic stripe CVD value failure.

D 590 Maximum Redemption Limit Met

Cust. SV Maximum redemption limit met.






D 591 Invalid CC Number

Cust. CC, DB, MP

Bad check digit, length or other credit card problem. Issuer generated.

D 592 Bad Amount Fix BML, CC

Amount sent was zero or unreadable. Issuer generated.

D 594 Other Error Fix BML, CC, DB, EC, ED, PY, SV,

SwP

Unidentifiable error. Issuer generated. BML – bill to country must be equal to U.S. PY – the invoice number is not unique, a contract ID is required, or amount, tax, shipping and handling amounts are formatted incorrectly.

D 595 New Card Issued

Cust. CC New Card Issued.

D 596 Suspected Fraud

Cust. CC Issuer has flagged account as suspected fraud.

D 597 Account Lookup Not Allowed for Merchant

Cust CC Account Lookup not allowed for merchant.

D 599 Refund Not Allowed

N/A PY Refund not allowed.

D 602 Invalid Institution Code

Fix CC Card is bad, but passes MOD 10 check digit routine, wrong BIN.

D 603 Invalid Institution

Cust. CC, DB Institution not valid (i.e. possible merger).

D 605 Invalid Expiration Date

Cust. BML, CC

Card has expired or bad date sent. Confirm proper date.

D 606 Invalid Transaction Type

Cust. CC, DB, MP, SV,

SwP

Issuer does not allow this type of transaction.

D 607 Invalid Amount

Fix CC, DB, ED, MP,

SV

Amount not accepted by network.






D 610 BIN Block Cust. CC Merchant has requested Merchant Services not process credit cards with this BIN. Note: Indicates customized code was used in processing.

D 615 Ineligible to Redeem

Cust. SwP Account is ineligible for Shop with Points. Accountholder should contact Issuer.

D 616 Non-participating Card

N/A SwP Account not participating in Shop with Points.

D 617 Not Enrolled in Shop with Points

Cust. CC, SwP

Accountholder not enrolled.

D 618 Unsuccessful Shop with Points Enrollment

Cust. SwP Register or Unregister action could not be processed..

D 621 Redemption Amount Below Minimum

N/A SwP Redemption amount is below Shop with Points program minimum.

D 622 Redemption Amount Above Maximum

N/A SwP Redemption amount is above Shop with Points program maximum.

D 627 No Matching Authorization Found

Fix SwP Authorization code incorrect.

D 719 On Negative File

Cust. ED Account number appears on European Direct Debit Internal Negative File.

R 740 Match Failed Fix DB, MP DB – Unable to find a match for Debit authorization record – based on trace number, account number, and transaction division number. MP – Unable to find a match for MoneyPak authorization record – based on transaction division number, amount, confirmation ID and account number.




Response


R 741 Validation Failed

Fix DB DB – Unable to validate the Debit authorization record – based on amount, action code, and MOP.

R 742 Unable to Process Transaction as Debit or Credit

Cust DB Unable to process transaction as debit or credit. Note: Merchant is enabled for PINless Debit BIN File Management.

D 747 Electronic Processing Not Supported

Cust. ED Issuing bank does not support electronic deposits, refunds, or mandates.

R/D 750 Invalid Transit Routing Number

Fix ECP, ED

ECP – ABA transit routing number is invalid, fails check digit. ED – Bank Sort Code is invalid.

R/D 751 Transit Routing Number Unknown

Fix ECP, ED

Transit routing number not on list of current acceptable numbers.

R 752 Missing Name Fix ECP, ED

Pertains to deposit and refund transactions only.

R 753 Invalid Account Type

Fix ECP Pertains to deposit and refund transactions only.

R/D 754 Account Closed Cust. CC, ECP,

ED, SV, PY

Bank account has been closed.

PY – the customer’s PayPal account was closed/restricted.

R 755 No Account/ Unable to Locate

Cust. ECP Does not match any account for the customer at the bank.

R 756 Account-Holder Deceased

Cust. ECP, ED

Customer or accountholder has died.

R 757 Beneficiary Deceased

Cust. ECP Beneficiary on account has died.

R 758 Account Frozen Cust. ECP, ED, SV

Transaction posting to account prohibited.

R/D 759 Customer Opt-out

Cust. ECP, ED, PY

Customer has refused to allow transaction. PY – the customer’s billing agreement was cancelled.

R/D 760 ACH Non-Participant

Cust. ECP, ED

ECP – Banking institution does not accept ACH transactions. ED – Bank does not allow direct debit.

R 763 Invalid Account Number

Cust. ECP, ED, MP,

SV

Account number is incorrect.






R 764 Authorization Revoked by Customer

Cust. ECP, ED

Customer has notified their bank not to accept these transactions.

R 765 Customer Advises Not Authorized

Cust. ECP Customer has not authorized bank to accept these transactions.

R 766 Invalid CECP Action Code

Fix ECP Invalid Action Code for Canadian ECP.

Valid Action Codes are: Refund Validate only Validate and Deposit

D 767 Invalid Account Number Format

Fix ECP, ED, MP

Formatting of account number is incorrect. ECP – Canadian account number greater than 12 digits. ED – Invalid account number or IBAN

R/D 768 Bad Account Number Data

Fix ECP, ED

Invalid characters in account number.

R 769 Invalid International ACH

Cust ECP International (excludes Canada) ACH not supported.

D 802 Positive ID Voice BML, CC

Issuer requires further information.

D 806 Restraint Cust. CC, SV Card has been restricted. D 811 Invalid

Security Code Fix CC American Express CID is incorrect.

D 813 Invalid PIN/User ID

Cust. BML, CC, DB

Invalid PIN or User ID.

BML and CC – Invalid User ID

DB – Invalid PIN

D 825 No Account Cust. CC, SV Account does not exist. D 833 Invalid

Merchant Fix BML,

CC, DB, ED, SwP

Service Establishment (SE) number is incorrect or Issuer does not allow this type of transaction.

Division not enabled at the Issuer

ED – merchant not set up at vendor






R/D 834 Invalid MOP / Unauthorized user

Cust. All R – Method of payment is invalid for the transaction division.

D – BML unauthorized user

D – Debit invalid MOP

D – ECP on Internal Negative File for unauthorized user.

D 835 No Permission

Cust. PY Customer does not have permission to refund the transaction.

D 902 Process Unavailable

Resend/ Call/ Cust.

BML, CC, DB, ED, MP, PY, SV,

SwP

System error/malfunction with Issuer.

BML – Decline from the processor.

DB – The link is down or setup issue; contact your Merchant Services Representative.

D 903 Invalid Expiration

Cust. CC Invalid or expired expiration date.

D 904 Invalid Effective Date

Cust./ Resend

BML, CC, PY

Card not active.

BML – Account may not yet be fully active.

PY – action is required by the customer.

D 905 Stand In Rules

Resend BML Declined authorization using stand-in rules.

Note: Authorization may be obtained when systems are available

D 910 PayPal Agreement has expired

Cust PY Customer’s billing agreement has expired.

D 911 Funding Source to expire

Cust PY 7–21 day notice that customer’s funding source will expire.

D 912 Account/ Agreement Updated

Cust PY Customer’s agreement description was updated.

D 913 Previous Agreement in Effect

Cust PY Customer cancelled upgrade to account; previous agreement in effect.

D 914 Buyer removed final funding source

Cust PY Customer removed final funding source from their account.




Authorization/ Verification Codes

The following Authorization/Verification Codes may be generated by Merchant Services to indicate the status of an authorized transaction based on your processing parameters.

Code Description notdep Not deposited rcycle Not deposited – transaction sent to Merchant Services

recycle program sofdep Deposited transaction with a soft decline tntCxx Test only (do not send in production) tstxxx Test only (do not send in production)


APPENDIX B: ADDRESS VERIFICATION Introduction The American Express Automated Address Verification (AAV) and the

Discover, Discover Diners, International Maestro, JCB, MasterCard, MasterCard Canadian Domestic Restricted Debit, and Visa Canadian Domestic Restricted Debit Visa Address Verification Service (AVS) are intended to reduce the fraudulent use of credit cards for mail, telephone, and other card not present transactions.

International Address Verification is defined as the card Issuer and the merchant being from two different countries. For example, a card Issuer in the U.S. and a merchant in the UK, or a card Issuer in Canada and a merchant in the U.S.

Domestic Address Verification is defined as the card Issuer and the merchant being from the same country. For example, both the card Issuer and the merchant are in Canada.

MasterCard may charge a fee for AVS responses. Address Verification is supported for ChaseNet.

Types of Address Records

Merchant Services supports two types of batch address records. One is formatted the other is not formatted.

The formatted address records are recommended for best AVS results.

JCB When JCB is referenced in this appendix, it only applies to U.S. merchants

processing USD currency.



APPENDIX B: ADDRESS VERIFICATION, (Continued)

Address Verification Process

Each verification process is executed by comparing the transmitted billing address with the billing address data that is kept on file for the accountholder. The Address Verification request is routed from the merchant through the Merchant Services system, directly to the specific credit card organization. The address information is then compared to the accountholder billing address on file.

The result of the Address Verification comparison is included in the authorization response message returned to the merchant. The Address Verification response is reflected as a two-character code (e.g., I3 or ID). In the Merchant Services address format, merchants may transmit either the zip/postal code only or multiple lines of address information. Merchant Services recommends Country Code be sent.

If formatted address records are sent for American Express transactions, data validation is not performed and all address information is sent to American Express.

For all other MOPs, if the country code sent on the record is "US", "CA", "GB", or "UK", but the zip/postal code is not properly formatted for the specified country, Merchant Services returns AVS Response Code "N2."

If formatted address records are sent and the country code is not populated on the record, the precedence for parsing the zip/postal code is:

1. Attempt a U.S. zip code format. 2. Attempt a Canadian postal code format. 3. Attempt a GB/UK postal code format. 4. Return AVS Response Code "N2". If unformatted address records are sent, country code should be populated or the address may not parse properly.

The number in the street address and any numeric street name must be sent in numeric form. For example, 123 FIRST STREET should be sent as 123 1ST STREET and ONE MAIN STREET as 1 MAIN STREET. Any apartment number associated with the address should follow directly after the street address on the same line.

For multiple street address lines, the line immediately preceding city, state, and postal code is used. Suite and apartment numbers should be included on the street address line.




American Express and JCB Canadian Merchants Advanced Verification

Merchant Services supports advanced verification for American Express and JCB Canadian merchants, which allows Merchant Services to receive verification responses for the following Bill To information:

• Name • Street • Postal Code • Phone • Email

To support full AAV for American Express and JCB Canadian merchants, the following records must be provided with online authorizations:

"RI" – Request Information (sending this enables email and phone AAV)

"LN" – Formatted Bill To Name "AB" – Bill To Address "HN" – Formatted Ship To Name "AS" – Ship To Address "AL" – Email Address (Address Subtype =B)

To support full AAV for American Express and JCB Canadian merchants, the following records must be provided with batch authorizations; these records are supported in the 120-Byte Batch Processing Format Specification:

"PRI" – Request Information (sending this enables email and phone AAV)

"LN" – Formatted Bill To Name "LA" – Formatted Bill To Address "LT" – Formatted Bill To Telephone "HN" – Formatted Ship To Name "HA" – Formatted Ship To Address "HT" – Formatted Ship To Telephone "AL" – Address Record (with Address type of L and Address

Subtype of B)

For American Express and JCB Canadian merchants address verification, the street address, street name and telephone number fields cannot be populated with all zeros and/or slashes.




American Express and JCB Canadian merchants Advanced Verification, (Continued)

The Enhanced Verification Flag must = Y and the formatted address records must be sent to receive these additional responses in the Response Information Reply Format Indicator and/or Record.

Advanced Verification Response Code

Description Comments

N Data does not match

R Retry American Express recommends retrying the verification process.

S Service not allowed

The Issuer does not provide this AVS service.

U Data unchecked

American Express did not validate data.

Y Data matches

Blank Data not sent The merchant did not send data or the data did not pass Merchant Services' edits.

Note: These responses are included in the following fields:

• Postal Code Verification Response • Street Verification Response • Name Verification Response • Phone Verification Response • Email Verification Response




Discover, Discover Diners, and JCB Address Verification Service

Merchant Services supports advanced verification for Discover, Discover Diners, and JCB, which allows Merchant Services to receive verification responses for the following Bill To information:

• Name

To support full Discover, Discover Diners, and JCB AVS, the following records must be provided with online authorizations:

"RI" – Request Information (sending this enables email and phone AAV)

"LN" – Formatted Bill To Name "AB" – Bill To Address

To support full Discover, Discover Diners, and JCB AVS, the following records must be provided with batch authorizations; these records are supported in the 120-Byte Batch Processing Format Specification:

"PRI" – Request Information (sending this enables email and phone AAV)

"LN" – Formatted Bill To Name "LA" – Formatted Bill To Address




Discover, Discover Diners, and JCB Address Verification Service, (Continued)

The Enhanced Verification Flag must = Y and the formatted address records must be sent to receive these additional responses in the Response Information Reply Format Indicator and/or Record.

Advanced Verification Response Code

Description Comments

B No name given with transaction

F First name matches, last name does not

K Unknown

L Last name matches, first name does not

M First and last names both match

N Data does not match

First and Last names do not match

P Not processed

W Data not sent

The merchant did not send data or the data did not pass Merchant Services’ edits.

U Retry

Discover, Discover Diners, and JCB recommend retrying the verification process.

Note: These responses are included in the following field:

• Name Verification Response




Address Verification Exceptions

For ChaseNet ,Visa, and Visa Canadian Domestic Restricted Debit MCCs that do not require AVS include:

• Government (9211, 9222, 9399) • School (8211, 8220, 8299) • Utility (4900) • Insurance (5960, 6300) • Cable and Other Pay TV (4899) • Child Care (8351) • Fuel Dealers (5983) • Subscriptions (5968) • Telecommunications (4814) • Real Estate Agents and Manager – rentals (6513) • Healthcare (4119, 5975, 5976, 7277, 8011, 8021, 8031, 8041, 8042,

8043, 8049, 8050, 8062, 8071, 8099) when Transaction Type = 1

AVS is not required for Bill Payment transactions unless Transaction Type = 5, 6, or 7. For Discover, MCCs that do not require AVS include:

• Insurance (5960, 6300) • Emerging Markets (4899, 5968, 5983, 6533, 8211, 8220, 8299, 8351,

8398) • Public Services (4784, 9211, 9222, 9223, 9311, 9399, 9405) • Hotels/Car Rentals (3351–3441, 3501–3999, 7011, 7012, 7512,

7513, 7519) • Passenger Transport (3000–3299, 4112, 4511)




AVS Response Codes

Response Explanation N1 No address given with order. N2 Bill-to address did not pass Merchant Services’ edit checks

(e.g., may be foreign). " " AVS not performed (Blanks returned). IG AVS not performed by International Issuer. Address

information unavailable for the account number (i.e. gift card), the card Issuer does not support AVS, or card Issuer declined authorization and did not perform AVS.

IU AVS not performed by Domestic Issuer. Address information unavailable for the account number (i.e. gift card), the card Issuer does not support AVS, or card Issuer declined authorization and did not perform AVS.

ID Issuer does not participate in AVS. IE Edit Error – AVS data is invalid. IS System unavailable or time-out. IA International street address and postal code match

(International Only). IB Street address match. Postal code not verified due to

incompatible formats (both were sent). IC Street address and postal code not verified due to

incompatible format (both were sent). IP Postal code match. Street address not verified due to

incompatible formats (both were sent). A1 Accountholder name matches. A3 Accountholder name, billing address and postal code match. A4 Accountholder name and billing postal code match. A7 Accountholder name and billing address match. B3 Accountholder name incorrect, billing address and postal code

match. B4 Accountholder name incorrect, billing postal code matches. B7 Accountholder name incorrect, billing address matches. B8 Accountholder name, billing address and postal code are all

incorrect. Zip/Postal Plus–4 Locale

I1 Match Match Match I2 Match Match No Match I3 Match No Match Match I4 Match No Match No Match I5 No Match Match Match I6 No Match Match No Match I7 No Match No Match Match I8 No Match No Match No Match




AVS Response Codes, (Continued)

Notes: A1-B8 are only returned for American Express transactions that use formatted address information.

Shaded codes in the preceding AVS Response Codes table are not provided by ChaseNet and Visa. They do not distinguish between Zip and Zip+4.

AVS Response Key

Item Definition ZIP/Postal Zip/Postal code Plus–4 4 digit portion of a 9-digit U.S. zip code Locale Street address, PO Box, or other local delivery destination A, B, I, R Responses from the Issuer or Network N Responses from Merchant Services Match Information presented in the record field matches the

information stored on the card Issuer’s file No Match Information presented in the record field does not match the

information stored on the card Issuer’s file.

Postal Code Format

U.S. Postal Code Format

Canadian Postal Code Format

United Kingdom Postal Code Format

NNNNN NNNNN–NNNN

ANA NAN ANANAN

AN NAA ANA NAA ANN NAA AAN NAA AANN NAA AANA NAA

N = Numeric A = Alpha

Notes: .. U.S. issued cards Address Verification is supported by: American Express, ChaseNet, Discover, Discover Diners, JCB, MasterCard, and Visa.

Canadian issued cards Address Verification is supported by: American Express, JCB, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit. United Kingdom (UK/GB) issued cards Address Verification is supported by:

American Express, International Maestro (for UK/GB domiciled merchants processing UK/GB issued cards), MasterCard, and Visa.

International issued cards Address Verification is supported by: American Express when using formatted address records.


APPENDIX C: ERROR SCREENING Bad Account Number Check

There are three common edits which catch the greatest majority of bad account numbers:

• MOD 10 check digit • Account number prefix check • Account number length check

MOD 10 Check Digit

The MOD 10 check digit routine validates the account number by calculating the last digit of the account number from all the other numbers in the account.



APPENDIX C: ERROR SCREENING, (Continued)

MOD 10 Check Digit, (Continued)

Example: Account number 5240159910151573

5 2 4 0 1 5 9 9 1 0 1 5 1 5 7 Start from the right and proceed to the left

until all digits are multiplied by weight

7*2=14 sum = 1 + 4 = 5

5*1=5 sum = sum (5) +5 =10

1*2=2 sum = sum (10) +2 =12

5*1=5 sum = sum (12) +5 =17

1*2=2 sum = sum (17) +2 =19

0*1=0 sum = sum (19) +0 =19

1*2=2 sum = sum (19) +2 =21

9*1=9 sum = sum (21) +9 =30

9*2=18 sum = sum (30) +1+8 =39

5*1=5 sum = sum (39) +5 =44

1*2=2 sum = sum (44) +2 =46

0*1=0 sum = sum (46) +0 =46

4*2=8 sum = sum (46) +8 =54

2*1=2 sum = sum (54) +2 =56

5*2=10 sum = sum (56) +1+0 =57 Remove the check digit, 3, which is already present in this example

sum = 57 sum MOD 10 → 57 MOD 10 = 7 10–7 = 3

check digit of 5240159910151573 is 3.




MOD 10 Check Digit, (Continued)

The following routine is a check digit routine written in the ‘C’ programming language.

/* The operator for mod in ‘C’ is % */ long mod10 (card,card_len-1) /* module 10 check digit function */ char *card; /* credit card number */ short card_len /* card length */ { register int count; /* a counter */ register int weight; /* weight to apply to digit being checked */ register int sum; /* sum of weights */ register int digit; /* digit being checked */ long mod;

weight=2; sum=0;

/* compute the sum */ for (count = card_len – 1; count >=0; count = count –1)

{ digit = weight * (card[count] – ‘0’); /* add both the tens digit and the ones digit to the sum */ sum = sum + (digit / 10) + (digit % 10); if (weight ==2)

weight = 1; else

weight = 2; }

/* subtract the ones digit of the sum from 10 and return the ones digit of that result */

mod = (10 – sum%10) % 10; return (mod) }




Account Number Prefix Check

The prefix check is the comparison of the first few bytes of each account number to a list of known prefixes.

The list of prefixes below is based on knowledge Merchant Services currently has and is subject to change.

Card Type Prefix American Express 37, 34 Bill Me Later 504990, 621993 Bill Me Later Private Label 621993 ChaseNet 4 Debit Unknown Discover 30, 36, 38, 39, 60, 62, 64, 65 Discover Diners 30, 36, 38, 39 Encryption Unknown European Direct Debit Unknown Gift Card 603571 International Maestro 50, 56 – 58, 6, 6759, 6767 JCB 3528 – 3589 MasterCard 22 – 27

51 – 55 MasterCard Canadian Domestic Restricted Debit

51 – 55

MoneyPak Unknown Visa 4

Visa Canadian Domestic Restricted Debit

4

Notes: For merchants enabled for ChaseNet MOP reassignment, when transactions are sent with MOP = VI, MOP = CR or CZ could be returned in the reply record.

If card prefix 30, 36, 38, or 39 are sent as Discover, MasterCard, or MasterCard Canadian Domestic Restricted Debit, Merchant Services processes and reports the transaction as Discover Diners. MOP = DD is returned in the reply records.

For U.S. merchants processing non-USD currency or Canadian merchants processing in non-Canadian currency, if card prefix 36 is sent as MasterCard, Merchant Services rejects the transaction with Response Reason Code 239 (Invalid MOP for Transaction Division).

If card prefix 6759 or 6767 are sent as UK Domestic Maestro, Merchant Services processes and reports the transaction as International Maestro. MOP = IM is returned in the reply record.




Account Number Length Check

A validation is performed by verifying the number of bytes for each account number.

Card Type Length American Express 15 Bill Me Later 16 Bill Me Later Private Label 16 ChaseNet 16 Debit 12 to 19 Discover 16 Discover Diners 14 (only for 36 prefix) or 16 Encryption 16 to 19 European Direct Debit Up to 16 European Direct Debit with IBAN Up to 34 Gift Card 19 International Maestro 13 to 19 JCB 16 MasterCard 14 (only for 36 prefix), 16 MasterCard Canadian Domestic Restricted Debit

14 (only for 36 prefix), 16

MoneyPak 14 to 20 PayPal 17 or 19 Visa 16

Visa Canadian Domestic Restricted Debit

16


APPENDIX D: INTERNATIONAL PROCESSING Introduction Merchant Services supports two types of international processing.

Multi-currency processing allows a merchant to collect payments from customers and receive settlement proceeds in the same currency.

Cross-currency processing allows a merchant to collect payments from customers in one currency and receive settlement proceeds in a different currency.

Contractual Agreement

The merchant is required to establish a separate contractual agreement with Merchant Services. Contractual agreements vary by country.

Transaction Division Numbers

Merchant Services assigns a unique transaction division number to process each international currency. A single transaction division number can support different transaction types and methods of payment in the same currency.

Zero Decimal Currency Example

Certain international currencies have zero decimals.

Since the amount field is two decimal implied: – to represent one Japanese Yen, (1=000000000100) – to represent one hundred Japanese Yen, (100=000000010000)

The Amount field must be populated with “00” in the two byte cents field or the transaction rejects with Response Reason Code 202 (Bad Amount Non-numeric Amount).



APPENDIX D: INTERNATIONAL PROCESSING, (Continued)

Multi-Currency Processing

Multi-currency processing allows a merchant to collect payments from customers and receive settlement proceeds in the same currency. This product is ideally suited for multi-national enterprises, or companies that have foreign currency requirements, desire to in-source foreign exchange management, or have foreign operations/obligations to fund.

Example: Merchant A markets a product/service in Australian Dollars, bills the customer in Australian Dollars, and receives an Australian Dollar settlement from Merchant Services.

Presentment/Settlement Currencies

ISO Currency

Code Currency Decimals

Australian Dollar 036 2 British Pound 826 2 Canadian Dollar 124 2 Danish Krone 208 2 Euro 978 2 Hong Kong Dollar 344 2 Japanese Yen 392 0 New Zealand Dollar 554 2 Norwegian Krone 578 2 South African Rand 710 2 Swedish Krona 752 2 Swiss Franc 756 2 U.S. Dollar 840 2

Notes: Bold Presentment Currencies have test divisions available.




Cross-Currency Processing

Cross-currency processing allows a merchant to collect payments from customers in one currency and receive settlement proceeds in a different currency. This product is ideally suited for merchants who are only domiciled in a single country (primarily the USA) and need to consolidate foreign currency settlement.

Example: Merchant B markets a product/service in Australian Dollars, bills the customer in Australian Dollars, and receives a U.S. Dollar settlement from Merchant Services.

Presentment Currencies

The following chart lists all presentment currencies, ISO currency codes, and currency decimals.

For American Express, all currencies are nine bytes in length.

Note: Please contact your Merchant Services Representative for supported Methods of Payment and settlement currencies.

Presentment Currencies ISO Currency Codes

Currency Decimals

Afghan Afghani 971 2 Albanian Lek 008 2 Algerian Dinar 012 2 Angolan Kwanza 973 2 Argentine Peso 032 2 Armenian Dram 051 2 Aruban Guilder 533 2 Australian Dollar 036 2 Azerbaijanian Manat 944 2 Bahamian Dollar 044 2 Bangladeshi Taka 050 2 Barbados Dollar 052 2 Belarussian Ruble 933 2 Belize Dollar 084 2 Bermudian Dollar 060 2 Bolivian Boliviano 068 2 Bosnia & Herzegovina

Convertible Marks 977 2

Botswana Pula 072 2




Presentment Currencies, (Continued)

Presentment Currencies ISO Currency

Codes Currency Decimals

Brazilian Real 986 2 British Pound 826 2 Brunei Dollar 096 2 Bulgarian Lev 975 2 Burundi Franc 108 0 Bhutanese Ngultrum 064 2 CFA Franc BCEAO 952 0 CFA Franc BEAC 950 0 CFP Franc 953 0 Canadian Dollar 124 2 Cambodian Riel 116 2 Cape Verdi Escudo 132 2 Cayman Islands Dollar 136 2 Chilean Peso 152 0 Chinese Yuan Renminbi 156 2 Colombian Peso 170 2 Comoro Franc 174 0 Congolese Franc 976 2 Costa Rican Colon 188 2 Czech Koruna 203 2 Danish Krone 208 2 Djibouti Franc 262 0 Dominican Peso 214 2 East Caribbean Dollar 951 2 Egyptian Pound 818 2 El Salvador Colon 222 2 Ethiopian Birr 230 2 Euro 978 2 Falkland Islands Pound 238 2






Currency Decimals

Fiji Dollar 242 2 Gambian Dalasi 270 2 Georgian Lari 981 2 Ghanaian Cedi 936 2 Gibraltar Pound 292 2 Guatemala Quetzal 320 2 Guinea Franc 324 2 Guinea-Bissau Peso 624 2 Guyanese Dollar 328 2 Haitian Gourde 332 2 Honduras Limpera 340 2 Hong Kong Dollar 344 2 Hungarian Forint 348 2 Iceland Krona 352 2 Indian Rupee 356 2 Indonesian Rupiah 360 2 Israeli New Shekel 376 2 Jamaican Dollar 388 2 Japanese Yen 392 0 Kazakhstan Tenge 398 2 Kenyan Shilling 404 2 Kyrgyzstan Som 417 2 Laos Kip 418 0 Lebanese Pound 422 2 Lesotho Loti 426 2 Liberian Dollar 430 2 Macau Pataca 446 2






Currency Decimals

Malagasy Ariary 969 2 Malawi Kwacha 454 2 Malaysian Ringgit 458 2 Maldive Rufiyaa 462 2 Mauritania Ouguiya 478 2 Mauritius Rupee 480 2 Mexican Peso 484 2 Moldovan Leu 498 2 Mongolia Tugrik 496 2 Moroccan Dirham 504 2 Mozambique New Metical 943 2 Myanmar Kyat 104 2 Namibia Dollar 516 2 Nepalese Rupee 524 2 Netherlands Antillean Guilder 532 2 New Guinea Kina 598 2 New Zealand Dollar 554 2 Nicaraguan Cordoba Oro 558 2 Nigerian Naira 566 2 Norwegian Krone 578 2 Pakistan Rupee 586 2 Panamanian Balboa 590 2 Paraguay Guarani 600 0 Peruvian Nuevo Sol 604 2 Philippines Peso 608 2






Currency Decimals

Polish Zloty 985 2 Qatari Rial 634 2 Romania Leu 946 2 Russian Ruble 643 2 Rwanda Franc 646 0 St. Helena Pound 654 2 Samoan Tala 882 2 Sao Tome & Principe Dobra 678 2 Saudi Riyal 682 2 Seychelles Rupee 690 2 Sierra Leonean Leone 694 2 Singapore Dollar 702 2 Solomon Islands Dollar 090 2 Somali Shilling 706 2 South African Rand 710 2 South Korean Won 410 0 Sri Lanka Rupee 144 2 Suriname Dollar 968 2 Swaziland Lilangeni 748 2 Swedish Krona 752 2 Swiss Franc 756 2 Taiwan Dollar (New) 901 2 Tajikistan Somoni 972 2 Tanzanian Shilling 834 2 Thai Baht 764 2 Tonga Pa’anga 776 2 Trinidad & Tobago Dollar 780 2






Currency Decimals

Turkish Lira 949 2 Uganda Shilling 800 2 0 Ukrainian Hryvnia 980 2 United Arab Emirates Dirham 784 2 Uruguayan Peso 858 2 U.S. Dollar 840 2 Uzbekistan Sum 860 2 Vanuatu Vatu 548 0 Vietnamese Dong 704 0 Yemeni Rial 886 2 Zambia Kwacha 967 2

Zimbabwe Dollar 716 2

Note: Bold Presentment Currencies have test divisions available.


APPENDIX E: CARD SECURITY VERIFICATION Introduction Merchant Services supports Card Security Verification (CSV) for American

Express, Bill Me Later Private Label, ChaseNet, Discover, Discover Diners, Gift Card, International Maestro, JCB, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit via the card association’s proprietary services. A card security value consists of an additional three or four-byte numeric identified on the card. Designed to target fraudulent transactions, Card Security Verification requires that the non-embossed three or four-byte numeric code on the back of the credit card be provided at the time of purchase. Statistics prove that much of the fraud in the non-face-to-face arena is perpetrated by individuals who know the account number, but are not in possession of the actual credit card.

When a merchant collects this value and passes it in the authorization request to Merchant Services, Merchant Services passes this data through the authorization system to the card Issuer or Gift Card server. The authorization response reflects whether that card security value for that specific card is accurate. Used in conjunction with the valid expiration date (credit card only), this service provides a valuable tool in assessing that the true accountholder has placed the order with you for your services or product.

It is against regulations to store this value.

American Express CID Program

When JCB is referenced in this section, it only applies to Canadian merchants processing CAD currency. These transactions are sent to American Express for processing.

The Card Identification (CID) number is printed, not embossed, on the laminated surface of all American Express and JCB cards and appears on the right border of the card. It consists of four bytes.

It is the goal of American Express to have merchants accepting card not present transactions to request the CID from the accountholder at the point of sale and include the CID in the transaction authorization request. The CID is then passed on to American Express and validated by their system.

Response Reason Code 811 (Invalid Security Code) may be returned when the CID value is provided, but does not match what American Express has on file. American Express may approve the transaction, however, the merchant should review the Card Security Value Response Code.



APPENDIX E: CARD SECURITY VERIFICATION, (Continued)

Bill Me Later Private Label VAK Program

The Virtual Authentication Key (VAK) is a three-byte numeric value located on the signature panel on the reverse side of the credit card. It is the last three digits which are pre-printed on the panel.

The rules for using the VAK are specified in the Bill Me Later Private Label merchant agreement. In general, the goal of this program is for the merchant to provide the VAK in all Card Not Present transactions at the time of sale.

Response Reason Code 531 (CVV2/VAK Failure) is ALWAYS returned if the VAK value is provided, but does not match what BillMeLater has on file.

Discover, Discover Diners, and JCB CID Program

When JCB is referenced in this section, it only applies to U.S. merchants processing USD currency. These transactions are sent to Discover for processing.

The Card Identification (CID) number is printed, not embossed, on the laminated surface of all Discover, Discover Diners, and JCB cards and appears on the right side of the signature panel. It generally consists of three bytes.

It is the goal of Discover to have merchants accepting card not present transactions to request the CID from the accountholder at the point of sale and include the CID in the transaction authorization request. The CID is then passed on to Discover and validated by their system.

Response Reason Code 503 (Fraud/Security Violation) is ALWAYS returned if the CID value is present, but does not match what Discover has on file.

International Maestro and MasterCard CVC2, MasterCard Canadian Domestic Restricted Debit CVV2 ChaseNet, Visa, Visa Canadian Domestic Restricted Debit CVV2 Program

Card Validation Code 2 (CVC2) and Card Verification Value 2 (CVV2) are three-byte numerics located on the signature panel on the reverse side of the credit card and are represented by the three digits following the account number.

Response Reason Code 531 (CVV2/VAK Failure) may be returned at the issuing bank’s discretion when the CVV2/CVC2 value is provided, but does not match what the Issuer has on file. The issuing bank may approve the transaction, however, the merchant should review the Card Security Value Response Code. MasterCard and MasterCard Canadian Domestic Restricted Debit may charge a fee for card security value responses. Visa and Visa Canadian Domestic Restricted Debit strongly recommend that merchants, domiciled in Great Britain that also accept Great Britain cards, send card security value information on all card not present transactions to avoid additional processing fees.




Gift Card CVD2 Program

Card Verification Data 2 (CVD2) is an optional feature determined by the merchant. The four-byte numeric value may be imprinted on the back of the card, and is used to facilitate a secure MOTO transaction when the customer wishes to use a Gift Card as their method of payment.

The transaction declines if the value sent by the merchant does not match the value in the system.

Guidelines for Populating Card Security Fields

All MOP’s

• If not performing Card Security Verification, do not send the fraud format indicator

• If Presence Indicator = blank or 1, Card Security Value must be present (three bytes) or the CSV Response = I

• If Presence Indicator = 2 or 9, Card Security Value must be blank or the CSV Response = I

All MOPs with Safetech Page Encryption and Tokenization

• If card security value is sent it should be encrypted, otherwise Merchant Services is not able to decrypt and process the transaction

• If Card Security Value = blank, Card Security Presence should equal 5

American Express

• The Presence Indicator should be "blank". If populated, it is ignored • Card Security Value must be present or the CSV Response = I

Bill Me Later Private Label

• If Presence Indicator = 1, Card Security Value should be present (three bytes).

• If Presence Indicator = 2 or 9, Card Security Value should be blank • CSV Response never = I • BillMeLater has requested no edit checks be performed by Merchant

Services for these fields.

Discover, Discover Diners, and JCB

• If Presence Indicator = 1, Card Security Value must be present (three bytes) or the CSV Response = I


• If Presence Indicator = blank, CSV Response = I




Guidelines for Populating Card Security Fields, (Continued)

Gift Card

• The Presence Indicator should be "blank". If populated, it is ignored • Card Security Value must be present (four bytes) or the CSV

Response = I

International Maestro, MasterCard, and MasterCard Canadian Domestic Restricted Debit

• If Presence Indicator = blank or 1, Card Security Value must be present (three bytes) or the CSV Response = I


ChaseNet ,Visa, and Visa Canadian Domestic Restricted Debit

• If Presence Indicator = 1, Card Security Value must be present (three bytes) or the CSV Response = I


• If Presence Indicator = blank, CSV Response = I

Card Types / Supported Currencies

American Express, Bill Me Later Private Label, Gift Card, International Maestro, MasterCard, Visa / All currencies Discover and Discover Diners / U.S. Dollars and Canadian Dollars ChaseNet and JCB (for U.S. merchants) / U.S. Dollars MasterCard Canadian Domestic Restricted Debit / Canadian Dollars Visa Canadian Domestic Restricted Debit / Canadian Dollars

Response Reason Codes

Appendix A: Response Reason Code Description/Usage

To Get Started

Contact your Merchant Services Representative.


APPENDIX F: AUTHORIZATION REVERSALS Introduction The merchant-initiated authorization reversal transaction can be sent

real-time or in a batch submission. The purpose of the authorization reversal is to free-up the accountholder’s Open To Buy, which has been reserved by the original authorization. This is done at the Issuer’s discretion.

Merchant-initiated authorization reversals for Shop with Points have no specific edits.

For Gift Cards, see Appendix P: Gift Cards for merchant initiated authorization reversal specific edits.

Merchant-initiated authorization reversals for all other MOPs have specific rules, edits, and response reason codes. Authorization reversals are reported in a separate section of the same reports as other authorizations.

How it works In order for the merchant to use Authorization Reversal functionality:

1. The original authorization must have been obtained through Merchant Services, or the transaction declines with Response Reason Code 307 (Authorization Not Found).

2. A merchant must always reverse the approved amount that was received in the authorization or the transaction rejects with Response Reason Code 306 (Amount Mis-match).

3. Authorization reversals should be sent to the same Merchant Services system as the original transaction.

4. Authorizations can be reversed via online for up to three days or the transaction rejects with Response Reason Code 307 (Authorization Not Found).

5. Authorizations can be reversed via batch for up to 7 – 10 days or the transaction rejects with Response Reason Code 307 (Authorization Not Found).

6. For batch authorization reversals, if extended authorization data is sent with the authorization reversal request, it is ignored.

7. If the Response Date and/or Authorization Code are not provided, the transaction rejects with Response Reason Code 262 (Authorization Code/ Response Date Invalid).



APPENDIX F: AUTHORIZATION REVERSALS, (Continued)

How it works, (Continued)

8. A merchant should never send an authorization reversal for an authorization request for which they did not receive an approval or the transaction declines with Response Reason Code 307 (Authorization Not Found).

9. The following criteria is used to find a matching authorization for the authorization reversal request:

a. Account Number b. Transaction Division Number c. Authorization Code d. Response Date e. Amount f. Order Number (Optional)

10. Successful authorization reversal requests return Response Reason Code 100 (Approval).




Transaction Types and Requirements

Online Request:

1. Online Processing Detail Record

a. Action Code = AR

b. Amount = approved, original, authorized amount

2. Format indicator

a. Prior Authorization (PA) or Prior Authorization and Reversal Reason Format Indicator (P4)

i. Response Date = approved, original, authorized date

ii. Authorization Code = approved, original, authorization code

Response:

1. Online Processing Return Format Record Batch Request:

1. Detail Record (“S” Record Input)

a. Action Code = AR

b. Amount = approved, original, authorized amount

c. Response Date = approved, original, authorized date

d. Authorization Code = approved, original, authorization code

Response:

1. "S" Record Output




Additional References

Appendix P: Gift Card

Appendix S: PayPal

Appendix AD: Shop with Points


American Express, Gift Card, International Maestro, JCB, MasterCard, PayPal, Visa / All currencies

Discover, Discover Diners / U.S. and Canadian Dollars

ChaseNet and Shop with Points / U.S. Dollars

MasterCard Canadian Domestic Restricted Debit / Canadian Dollars

Visa Canadian Domestic Restricted Debit / Canadian Dollars



To Get Started Contact your Merchant Services Representative.


APPENDIX G: PARTIAL AUTHORIZATION Introduction Partial authorization functionality allows a merchant to receive an approval for

a portion of the original amount when the full amount cannot be approved. Defaults for partial authorization handling are set at the transaction division level. In some instances the defaults can be overridden at a transaction level. This appendix provides the details for processing partial authorizations.

How It Works Default Set Up for the Merchant’s Transaction Division

Default settings are entered into the Merchant Services processing system to manage the outcome of a partial authorization request at the transaction division level. If the merchant’s transaction division is set to a default to either allow or not allow a partial authorization, the default can be overridden at the transaction level for ChaseNet, Debit, Discover, Discover Diners, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, MoneyPak, Visa, and Visa Canadian Domestic Restricted Debit. The transaction division default cannot be overridden for American Express and JCB. Conditional Deposits and Deposits

Partial authorizations cannot be performed on Conditional Deposit transactions.

If a Deposit transaction is re-authorized per Merchant Services’ normal process for obtaining best interchange, a partial authorization is not performed.



APPENDIX G: PARTIAL AUTHORIZATION, (Continued)

American Express and JCB

For American Express and JCB the following chart lists conditions and results when populating the Partial Redemption Indicator Flag.

REQUEST REPLY Transaction

Division Default

Partial Redemption

Indicator Flag

Amount of Authorization

Response Reason Code

Current Balance

Redemption Amount

1 N 263

1 Y or not sent

Greater than available balance

100 Populated with

approved, authorized,

amount 1 Y or not

sent Less than or

equal to available balance

100

2 Y 263

2 N or not sent


Decline Populated with

available balance

2 N or not sent

Less than or equal to available balance

100

3 Y or not sent


100 Populated with

approved, authorized

amount 3 N Greater than

available balance

Decline Populated with correct

available balance

3 Y or not sent


100

3 N Less than or equal to available balance

100

0 Y or N 263




American Express and JCB, (Continued)

American Express and JCB Transaction Division Default Keys:

1 Do partial authorization and return redemption amount if authorized amount > available balance.

2 Decline if the amount is > available balance and return current balance (Partial Authorization not allowed).

3 Merchant is able to support the actions of transaction division defaults ‘1’ and ‘2’.

0 Transaction Division has not been certified with American Express for Partial Authorization

Note: If Partial Redemption Indicator Flag is not sent with the transaction the transaction division default is used. If the transaction division default is ‘3’, a partial authorization is attempted.




Discover and Discover Diners

For Discover and Discover Diners the following chart lists the conditions and results when populating the Partial Redemption Indicator Flag.

Notes: The sale amount must be approved before the cash back amount may be fully or partially approved.

If the transaction amount is greater than the available balance, then the Redemption Amount is returned for transactions that are approved.

REQUEST REPLY

Partial Redemption

Indicator Flag

/ Transaction

Division Default


Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

B / 1 Greater than or equal to available balance

Y 100

May be populated

with available balance

Populated with


amount

Zero filled

Bal = $70.00 $80.00 $20.00

May be populated


$70.00 $0.00

B / 1 Less than available balance

Y Plus sale amount is

greater than available balance

100

May be populated


Populated with


amount

Populated with


amount

Bal = $70.00 $60.00 $20.00

May be populated


$60.00 $10.00


Y Plus sale amount is less than available balance

100

May be populated


Populated with


amount

Bal = $70.00 $40.00 $20.00

May be populated


$20.00




Discover and Discover Diners, (Continued)

Discover and Discover Diners Chart, (Continued) REQUEST REPLY

Partial Redemption

Indicator Flag /

Transaction Division Default


Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved


Y Plus sale amount is equal to available balance

100

May be populated


Populated with


amount

Bal = $70.00 $50.00 $20.00

May be populated


$20.00

B / 1


N 100

May be populated


Bal = $70.00 $70.00

May be populated


B / 1 Greater than

available balance

N 100

May be populated


Populated with


amount

Bal = $70.00 $80.00

May be populated


$70.00






Partial Redemption

Indicator Flag /



Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

C / 3 Greater than

available balance

Y Declined

May be populated


Zero filled

Bal = $70.00 $80.00 $20.00

May be populated


$0.00

C / 3 Equal to available balance

Y 100

May be populated


Populated with approved, authorized

amount

Zero filled

Bal = $70.00 $70.00 $20.00

May be populated


$70.00 $0.00

C / 3 Less than available balance

Y • 100

• May be

populated with

available balance

Populated with


amount

Bal = $70.00 $40.00 $20.00

May be populated


$20.00

C / 3 Less than available balance


greater than

available balance

100

May be populated


Populated with approved, authorized

amount

Populated with


amount

Bal = $70.00 $60.00 $20.00

May be populated


$60.00 $10.00






Partial Redemption

Indicator Flag /



Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

C / 3 Less than or


N 100

May be populated


Bal = $70.00 $70.00

May be populated


C / 3 Greater than

available balance

N Declined

May be populated


Bal = $70.00 $80.00

May be populated







Partial Redemption

Indicator Flag /


Amount of

Authorization

Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

N / 0 Less than or


Y Plus Cash

Back amount is less than

or equal to available balance

100

May be populated


Populated with


amount

Bal = $70.00 $50.00 $20.00

May be populated


$20.00

N / 0


Y Plus Cash

Back amount is


Declined

May be populated


Zero filled

Bal = $70.00 $60.00 $20.00

May be populated


$0.00

N / 0


N 100

May be populated


Bal = $70.00 $70.00

May be populated


N / 0 Greater than

available balance

N Declined

May be populated


Bal = $70.00 $80.00

May be populated







Partial Redemption

Indicator Flag /



Cash Back Amount

Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

Y / 2

Less than, greater than or equal to available balance



100

May be populated


Populated with


amount

Zero filled

Bal = $70.00 $80.00 $20.00

May be populated


$70.00 $0.00

Y / 2 Less than available balance


less than or equal to available balance

100

May be populated


Populated with


amount

Bal = $70.00 $50.00 $20.00

May be populated


$20.00

Y / 2

Less than, or equal to available balance

N 100

May be populated


Bal = $70.00 $70.00

May be populated


Y / 2 Greater than

available balance

N 100

May be populated


Populated with


amount

Bal = $70.00 $80.00

May be populated


$70.00






Partial Redemption

Indicator Flag /



Cash Back Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

X / 4 Greater or

equal to than available balance

Y Decline

May be populated


Zero filled

Bal = $70.00 $80.00 $20.00

May be populated


$0.00

X / 4 Less than available balance


less than or equal to available balance

100

May be populated


Populated with


amount

Bal = $70.00 $50.00 $20.00

May be populated


$20.00

X / 4 Less than available balance



100

May be populated


Populated with approved,

authorized amount

Zero filled

Bal = $70.00 $60.00 $20.00

May be populated


$60.00 $0.00






Partial Redemption

Indicator Flag /


Sale Amount

Cash Back Requested


Current Balance

Redemption Amount

Cash Back Amount

Approved

X / 4 Greater

than available balance

N Decline

May be populated


Bal = $70.00 $80.00

May be populated


X / 4


N 100

May be populated


Bal = $70.00 $70.00

May be populated






Discover and Discover Diners Transaction Division Default Keys :

0 Merchant does not support partial authorization. Partial authorization not allowed for both sale amount and cash back amount.

1 Both sale amount and cash back may be partially approved. The sale amount must be fully approved before the cash back amount can be partially approved.

2 The sale amount can be partially approved but the cash back amount cannot be partially approved.

3 The sale amount must be fully approved before the cash back amount may be partially approved.

4

Merchant may support partial auth, but the sale amount must be fully approved before the cash back amount can be approved. Neither the sale amount nor the cash back amount can be partially approved.

Notes: If Partial Redemption Indicator Flag is not sent with the transaction, the transaction division default is used.

If Discover returns a current balance on the authorization, it is returned with the transaction response.




ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit

For ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit the following chart lists the details when populating the Partial Redemption Indicator Flag.

REQUEST REPLY Partial Redemption

Indicator Flag/ Transaction Division

Default



Current Balance

Redemption Amount

Y/1 Greater than available balance

100 May be populated


(should be $0.00)

Populated with


amount

N/1 Greater than available balance

Decline

Y/1 Less than or equal to available balance



N/1 Less than or equal to available balance

100




(should be $0.00)

Populated with

approved authorized

amount

N/0 Greater than available balance

Decline

Y/0 Less than or equal to available balance



N/0 Less than or equal to available balance

100




ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit, (Continued)

ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit Transaction Division Default Keys:


0 Partial authorization not allowed – no return of current balance. Notes: If Partial Redemption Indicator Flag is not sent with the transaction the transaction division default is used.

If ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, or Visa Canadian Domestic Restricted Debit returns a current balance on the authorization, it is returned with the transaction response.

Fuel transactions (MCC = 5542) behave differently. Contact your Merchant Services Representative for details.

For MasterCard and MasterCard Canadian Domestic Restricted Debit fuel transactions where partial authorizations are enabled, the redemption amount can be greater than the amount of the transaction.





MoneyPak For MoneyPak the following chart lists the details when populating the Partial Redemption Indicator Flag.

REQUEST REPLY

Partial Redemption

Indicator Flag/ Transaction

Division Default



Current Balance

Redemption Amount


100 Populated with


amount N/1 Greater than

available balance Decline

Y/1 Less than or equal to available

balance

100

N/1 Less than or equal to available

balance

100


100 Populated with

approved authorized

amount N/0 Greater than

available balance Decline

Y/0 Less than or equal to available

balance

100

N/0 Less than or equal to available

balance

100

MoneyPak Transaction Division Default Keys:


0 Partial authorization not allowed – no return of current balance. Note: If Partial Redemption Indicator Flag is not sent with the transaction the transaction division default is used.



PIN-Based Debit

For PIN-Based Debit the following chart lists the details when populating the Partial Redemption Indicator Flag.

REQUEST REPLY

Partial Redemption


Division Default


Cash Back Amount

Requested


Redemption Amount

Cash Back

Amount Approved

Y/0 or

Y/1


Y Plus Cash



100 Populated with

approved authorized

amount

Populated with

approved amount

$70.00 $50.00 $20.00 $50.00 $20.00 Y/0 or

Y/1


N 100 Populated with


amount

$70.00 $80.00 $70.00

Y/0 or

Y/1


Y Plus Cash

Back amount is

greater than

available balance

100 Populated with


amount

Zero filled

$70.00 $50.00 $50.00 $50.00 $0.00 Y/0 or

Y/1


Y Plus Cash

Back amount is

greater than

available balance

100 Populated with


amount

Zero filled

$70.00 $80.00 $50.00 $70.00 $0.00




PIN-Based Debit, (Continued)

For PIN-Based Debit, (continued) REQUEST REPLY

Partial Redemption


Division Default


Cash Back Amount

Requested


Redemption Amount

Cash Back

Amount Approved

N/0 or

N/1


Y Plus Cash



100 Populated with

approved authorized

amount

Populated with

approved amount

$70.00 $50.00 $20.00 $50.00 $20.00 N/0 or

N/1


N Decline

$70.00 $80.00

N/0 or

N/1


Y Plus Cash

Back amount is

greater than

available balance

100 Populated with


amount

Zero filled

$70.00 $50.00 $50.00 $50.00 $0.00 N/0 or

N/1


Y Plus Cash

Back amount is

greater than

available balance

Decline Zero filled

$70.00 $80.00 $50.00 $0.00




PIN-Based Debit, (Continued)

PIN-Based Debit Transaction Division Default Keys:

1 The sale amount can be partially approved but the cash back amount cannot be partially approved.

0 Partial authorization not allowed. Note: If Partial Redemption Indicator Flag is not sent with the transaction the transaction division default is used.





The following transaction requirements describe authorizations for Credit Card transactions. Online Request:


a. Action Code = AU

2. Format indicator

a. Partial Authorization (PB)

Response:

1. Online Processing Return Format Record

2. Reply Format Indicator

a. Partial Authorization (PB) (Optional) Batch Request:


a. Action Code = AU

2. Product Record

a. Partial Authorization (PPB001)

Response:


2. Product Record

a. Partial Authorization (PPB001) (Optional)




Transaction Types and Requirements, (Continued)

The following transaction requirements define MoneyPak transactions. Online Request:


a. Action Code = PA

b. MOP = MP

2. Format Indicators

a. Partial Authorization (PB)

b. MoneyPak (MP)

Response:


2. Reply Format Indicators

a. Partial Authorization (PB) (Optional)

b. MoneyPak (MP) (Optional) Batch Request:


a. Action Code = PA

2. Extension Record

a. MoneyPak (EMP001) (Optional)

3. Product Record

a. Partial Authorization (PPB001)

Response:


2. Extension Record


3. Product Record





Transaction Types and Requirements for PIN-Based Debit

The following transaction requirements describe authorizations for PIN-Based Debit transactions.

Online Request:


a. Action Code = PA


a. Debit Information (DB)

b. Retail (RE) or Retail 3 (R3)

i. Track 2 data is required.

c. Retail Partial Authorization (PB)

Response:



a. Debit (DB)

i. Trace Number

b. Partial Authorization (PB) (Optional)





American Express, International Maestro, JCB, MasterCard, MoneyPak, Visa / All currencies.

Discover and Discover Diners / U.S. and Canadian Dollars

ChaseNet / U.S. Dollars

MasterCard Canadian Domestic Restricted Debit \ Canadian Dollars






APPENDIX H: VERIFIED BY VISA Introduction Verified by Visa is a solution designed to authenticate accountholders when

paying online.

Created to add a new level of security to Internet transactions, Verified by Visa is an innovative online service that verifies an accountholder’s ownership of an account, in "real-time", during an online payment transaction. Verified by Visa gives ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit card Issuers the ability to confirm an accountholder’s identity using a variety of authentication methods, including passwords, chip cards and digital certificates. Providing merchants with "real-time" authentication results during the checkout process, Verified by Visa creates a safer and more cost-effective e-Commerce solution for merchants and customers. Verified by Visa is based on the 3-D Secure Protocol, which uses Secure Sockets Layer (SSL) encryption to collect and protect payment card information transmitted via the Internet. Verified by Visa defines three domains for the authentication process:

• Issuer Domain – where the Issuer is responsible for determining whether authentication is available for the card account presented in a purchase.

• Acquirer Domain – Where the Acquirer accepts Internet transaction data from the merchant and passes it to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

• Interoperability/ ChaseNet and Visa Domain – operated by ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit, where transaction information is exchanged and stored using 3-D Secure as the common protocol.

How It Works The accountholder shops at participating Internet merchants with no changes

to the shopping or checkout. The accountholder selects the merchandise to be purchased and proceeds to the checkout. At the checkout the accountholder may complete the purchase and payment information in a variety of ways, including self-entered, electronic wallet, merchant one-click, or using other checkout capabilities.

After the purchase and payment information is entered, the accountholder selects the "buy" button. This activates the Merchant Server Plug-In (MPI) software application, which checks its local cache to determine if the ChaseNet, Visa or Visa Canadian Domestic Restricted Debit Issuer BIN participates in Verified by Visa. If the BIN is participating, the MPI generates an inquiry to the Visa Directory Server to determine if the accountholder’s account is enrolled in Verified by Visa. The Visa Directory Server sends a Verify Enrollment Request message to the Issuer Access Control Server (ACS) to determine if authentication is available for the accountholder’s account number. The Visa Directory Server sends the Issuer ACS response to the MPI.



APPENDIX H: VERIFIED BY VISA, (Continued)

How It Works, (Continued)

If authentication is not available, the merchant server receives an "authentication not available" message and returns the transaction to the merchant’s commerce server to proceed with a standard Authorization Request.

If authentication is available, the message response provides the URL for the Issuer ACS where the accountholder can be authenticated. The MPI sends a message and script directing the accountholder’s browser to establish a pop-up session with the Issuer ACS.

The browser directs the transaction to the URL specified for the Issuer ACS creating an SSL session. The Issuer ACS displays a pop-up window to the accountholder. The window includes Issuer-specific, ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit branding, transaction details-including merchant name and sale amount, and prompts the accountholder to enter their password.

The accountholder is allowed a limited number of password attempts, typically 3 to 5, as defined by the Issuer ACS. If unable to correctly enter the password, the accountholder may access the password hint that was established during registration. If the password is entered correctly, the transaction continues. If the accountholder is not registered, the ACS briefly displays a processing window and the transaction continues as an attempted authentication. If the password is incorrectly entered more times than the Issuer limit, a failed Payer Authentication Response is returned to the merchant.

The Issuer ACS retrieves the authentication information and compares it against the data that was registered during the initial registration process. If the data matches, a success page is presented to the accountholder and the Issuer ACS sends a message through the browser to the merchant, thus providing evidence of accountholder authentication. Using the Issuer’s encryption keys and transaction data, the Issuer server calculates the Cardholder Authentication Verification Value (CAVV), which is included with the Electronic Commerce Indicator (ECI), as provided at the time of authentication by the MPI, in the response to the merchant.

The Issuer ACS creates, digitally signs, and sends a Payer Authentication Response to the accountholder’s browser, and sends transaction information to the Visa Authentication History Server (AHS) for storage. All Payer Authentication Response messages – successful, unable to authenticate, failed, and attempted authentications – are transmitted and stored in the AHS. The browser routes the Payer Authentication Response back to the MPI. The MPI validates the digital signature in the response, verifying that it is from a valid participating Issuer. If the digital signature is verified and the Issuer has sent an approved Payer Authentication Response, the accountholder is deemed authenticated and the MPI returns the transaction to the storefront software. The merchant starts processing the order, determining whether it can be fulfilled, and calculating taxes and shipping for the total transaction amount.





A merchant may not submit for authorization a purchase transaction that has failed authentication.

For a fully authenticated transaction, the merchant sends the CAVV with Transaction Type = 5 to Merchant Services.

If the Visa Authentication record is sent without the CAVV, the CAVV is not sent in Base 64 encoding, or is sent for a non-e-Commerce transaction, Response Reason Code 245 (Missing or Invalid Secure Payment Data) is returned.

Merchant Services passes the CAVV and Transaction Type to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit with the authorization request. These fields are used during authorization processing to verify that authentication, or attempted authentication, was performed and to qualify for the e-Commerce Custom Payment Services.

The Issuer receives the authorization request and validates the CAVV and responds with a CAVV response code, as well as an approval or a decline of the authorization. If the CAVV does not match, the Issuer should decline the transaction.

Non-participating Verified by Visa/ChaseNet Issuers: Participating Verified by Visa merchants that attempt to authenticate an accountholder and the Issuer is not participating in Verified by Visa may receive a CAVV. Merchants must pass these transactions with Transaction Type = 6 and the CAVV value returned at authentication time.




Merchant Requirements

The merchant must install a certified 3-D Secure Merchant Plug-in software application.

The merchant must verify that Merchant Plug-in provides CAVV in Base 64 encoding. If not, the merchant must convert data fields to Base 64 encoding before sending to Merchant Services.

In the settlement of a Verified by Visa transaction, merchants are strongly encouraged to submit the Visa Authentication Extension Record. In the event that Merchant Services has to perform a new authorization, the authentication data (CAVV) is included in the new authorization. By doing so, the merchant maintains the Verified by Visa chargeback liability shift and the best interchange rate.

Merchants must map the Visa Electronic Commerce Indicator (ECI) they receive via their MPI to the appropriate Merchant Services Transaction Type:

Transaction Description

Visa ECI Returned in MPI

Merchant Services Transaction Type

Fully Authenticated 5 5

Attempted Authentication

6 6

Failed or No Response From ChaseNet, Visa, or Visa Canadian Domestic Restricted Debit

No ECI returned DO NOT send transaction for authorization

Visa strongly recommend that merchants domiciled in Italy use Verified by Visa on all e-Commerce transactions to avoid additional processing fees.




Failed Authenti-cations

Merchants are prohibited from submitting transactions for authorization that have failed authentication.

Split Shipments

When a participating merchant splits the shipment of an order, each authorization component may be submitted with the authentication data of the original purchase. In the event of a dispute, the Acquirer must be able to establish that the authorization requests were related to a single customer authenticated purchase. If a deposit is sent for the subsequent shipment, the authorization would have been flagged as "used" in our Previous Order Database (PODB) by the first deposit item. In order to receive the Verified by Visa chargeback protection, a merchant must send the original authentication data with each subsequent deposit record for reauthorization purposes.

Example of Verified by Visa – Split Shipment/Split Deposit within the Visa 7 day authorization window:

On July 1, a customer purchases two items from a participating Verified by Visa Merchant. The merchant sends an authorization for $100.00 to Merchant Services, including the authentication data (CAVV and Transaction Type).

On July 2, the merchant sends a deposit record for only one of the items, totaling $75.00, along with authentication data. Merchant Services performs an authorization reversal (due to Visa Regulations) to change the dollar amount of the original authorization on July 1 to match the deposit dollar amount of $75.00.

On July 5, the merchant sends a deposit record totaling $25.00 for the second item. In order for the merchant to receive chargeback protection on the second item being deposited, they must send the deposit record with the original authentication data from the original authorization performed on July 1. Merchant Services reauthorizes the second item because the original authorization would have been flagged as "used" in PODB by the first deposit item.




Late Fulfillment

If the transaction date (shipment) exceeds the time limit from the authorization date for interchange qualification, the participating merchant is required to submit a new authorization request. The authentication data of the original purchase, when supported by the merchant, should be included in the new authorization request. In the event of a dispute, the Acquirer must be able to establish that the second authorization request was related to the same original transaction.

Recurring Transactions

When a participating Merchant offers services of an ongoing nature to an accountholder for which the accountholder pays on a recurring basis (for example, insurance premiums, subscriptions, Internet service provider fees, membership fees, tuition, or utility charges), the accountholder payments are considered recurring payments, as defined in the Visa U.S.A. Inc. Operating Regulations. If the first payment originated as an Electronic Commerce Transaction via the Internet, it must be submitted for authorization with the appropriate Electronic Commerce Indicator (ECI of 5 or 6) value, including Verified by Visa authentication data (CAVV), if applicable. If these transactions are disputed as not made or not authorized by the accountholder, the Issuer is not permitted to charge the transaction back for Reason Codes 23, 61, 75, or 83. All subsequent payments must be submitted for authorization using Transaction Type 2 (Recurring). The Merchant must not store and submit the CAVV with any subsequent transaction. Because accountholders may dispute that they did not authorize the recurring payments charged to their account, subsequent recurring payments are subject to chargeback if disputed by the accountholder for the reason codes above.

Online Auctions

Participating merchants that offer online auctions may submit a valid CAVV and appropriate Transaction Type for an authentication or attempted authentication transaction in the authorization request message, even though the purchase amount may have changed from the authentication request to the authorization request. A CAVV may not be reused for another transaction with the same accountholder (for example, on another auction).




Chargeback Liability Shift Exclusions

There are certain exclusions from the chargeback provisions related to attempted authentications. They are:

1. Anonymous Prepaid Cards (such as gift cards), and transactions from new channels (such as mobile devices), are excluded from chargeback protections for attempted authentications. If these cards are enrolled in Verified by Visa and the Issuer authenticates the accountholder, the Issuer is not permitted to submit a chargeback for unauthorized usage disputes (reason codes 23, 61, 75, and 83). Either the Issuer ACS or Visa may designate excluded transactions; however, the Visa Directory Server overrides excluded responses from an Issuer ACS if the BINs are not also designated as excluded BINs in the Visa Directory. The designation of BINs as Anonymous Prepaid Cards must be consistent with VisaNet.

2. Transactions conducted in new channels (such as mobile or wireless devices).

3. Merchants named in the Global Merchant Chargeback Monitoring Program are not eligible for chargeback protection for attempted authentications during the time that they are required to participate in the program and three months thereafter. Visa works with Acquirers to ensure compliance with this requirement. There are no additional steps for Issuers regarding this provision.





Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = CR, CZ, VI, or VR

c. Transaction Type = 5 or 6

2. Format Indicator

a. Visa Authentication (VA)

Response:


a. CAVV Response Code

Batch Request:

1. Detail Record ("S" Record Input)

a. Action Code = AU



2. Extension Record

a. Visa Authentication (EVI002)

Response:


2. Extension Record






Conditional Deposit deposits this transaction ONLY if a valid authorization is obtained.

Batch Request:


a. Action Code = DC



2. Extension Record


Response:


2. Extension Record






Deposits this transaction REGARDLESS of authorization status.

Batch 1. Detail Record ("S" Record Input)

a. Action Code = DP



2. Extension Record


Response:


2. Extension Record



Visa / All currencies ChaseNet / U.S. Dollars Visa Canadian Domestic Restricted Debit / Canadian Dollars



To Get Started



APPENDIX I: MASTERCARD SECURECODE

Introduction MasterCard SecureCode is a solution designed to authenticate accountholders when paying online. SecureCode offers a mechanism for securing the Internet channel by strongly authenticating the accountholder at the point of interaction by providing a unique transaction-specific token that provides evidence that the accountholder originated the transaction. SecureCode uses MasterCard’s Universal Cardholder Authentication Field (UCAF) infrastructure to communicate the authentication information among the accountholder, Issuer, merchant and Acquirer.

MasterCard SecureCode supports the 3-D Secure Protocol. MasterCard SecureCode requires merchants to install a 3-D Secure v1.0.2 compliant Merchant Server Plug-In software application.

International Maestro supports the same SecureCode features as MasterCard.

How It Works The accountholder shops at a participating SecureCode Internet Merchant with no changes to the shopping or checkout. The accountholder selects the merchandise to be purchased and proceeds to the checkout. At the checkout, the accountholder may complete the purchase and payment information in a variety of ways, including self-entered, electronic wallet, merchant one-click, or using other checkout capabilities.

After the purchase and payment information is entered, the customer hits the "buy" button and the Confirmation page goes back to the merchant.

The merchant plug-in (MPI) activates and checks its local cache and the MC Directory Server to determine if the customer card number is part of a participating MasterCard SecureCode BIN range. If so, a Verify Enrollment Request message is sent from the MPI, to the MC Directory Server and forwarded to the Issuer Access Control Server (ACS) to determine if authentication is available for the accountholder’s account number. The MC Directory Server sends the Issuer ACS response to the MPI. If authentication is available, the message response provides the web address for the Issuer ACS where the accountholder authentication begins. (If authentication is not available, the merchant server receives an "authentication not available" message and returns the transaction to the merchant’s commerce server to proceed with a standard Authorization Request.)

The MPI sends a message and script directing the accountholder’s browser to establish a session with the Issuer ACS to perform authentication. The in-line authentication window displays Issuer-specific and MC branding, transaction details – including merchant name and sale amount, and prompts the accountholder to enter their secure code (e.g. password). If the password is entered correctly, the transaction continues.



APPENDIX I: MASTERCARD SECURECODE, (Continued)


The accountholder is allowed a limited number of password attempts, typically three to five, as defined by the Issuer ACS. If unable to correctly enter the password, the accountholder may access the password hint that was established during registration. If the password is incorrectly entered more times than the Issuer limit, a failed Payer Authentication Response is returned to the merchant.

The Issuer ACS retrieves the authentication information and compares it against the data that was registered during the initial accountholder registration process. If the data matches, a success page is presented to the accountholder and the Issuer ACS sends a message through the browser to the merchant providing evidence of accountholder authentication, including a 28-byte AAV. This AAV is generated cryptographically using Issuer-specific secret keys that are synchronized with keys at the Issuer’s authorization platform.

For a fully authenticated transaction, the merchant sends the AAV with Transaction Type = 5 to Merchant Services.

If the MasterCard Authentication record is sent without the CAVV, the CAVV is not sent in Base 64 encoding, or is sent for a non-e-Commerce transaction, Response Reason Code 245 (Missing or Invalid Secure Payment Data) is returned.

Merchant Services passes the AAV and Transaction Type to MasterCard with the authorization request. These fields are used during authorization processing to verify that authentication, or attempted authentication, was performed and to qualify for the e-Commerce Custom Payment Services.

Activation During Shopping (ADS): Accountholders that are not enrolled in SecureCode may be presented with an enrollment window while shopping at a SecureCode merchant’s website. Unlike the traditional enrollment process, ADS does not require the customer to visit an enrollment web site before shopping. This type of enrollment takes place during the shopping process. When an eligible customer goes to checkout, the card-issuing bank asks a series of questions – similar to the traditional enrollment process. Providing the correct answers results in both a successful enrollment and a successful authentication response returned to the merchant. The merchant must send the AAV they receive to Merchant Services, along with Transaction Type of 5. If the accountholder chooses to opt-out of enrollment during shopping, the Issuer passes an AAV to the merchant. In this case, the merchant is not required to submit the AAV with the authorization, but must send Transaction Type of 6.





Non-participating MasterCard SecureCode Issuers: Participating MasterCard SecureCode merchants that attempt to authenticate an accountholder where the Issuer is not participating in MasterCard SecureCode the issuer return an AAV. Merchants must pass these transactions with Transaction Type = 6.

Processing Requirements for Merchants Using International Maestro and the Maestro Advanced Registration Program or the MasterCard Advanced Registration Program (MARP)

Both the Maestro Advanced Registration Program and the MasterCard Advanced Registration Program (MARP) allow enrolled merchants to accept Maestro and MasterCard cards for e-commerce transactions without using SecureCode for every transaction. However, merchants are required to perform a full authentication on the first transaction they perform for any individual accountholder. An enrolled MARP merchant is provided with a static Accountholder Authentication Value (AAV) for use with transactions that are processed without SecureCode authentication.

Once a merchant has registered in the MARP (either the Maestro program, the MasterCard program, or both), all accountholders must go through the SecureCode process again, regardless of whether the accountholder has gone through SecureCode prior to the merchant’s registration. After the accountholder has gone through SecureCode and has been approved, the accountholder is not required to go through SecureCode for subsequent transactions. The Method of Payments affected are IM (International Maestro) and MC (MasterCard) for European merchants.

For the first International Maestro or MasterCard e-commerce transaction, the merchant must request SecureCode authentication before submitting the transaction for authorization. If that transaction is subsequently authorized by the issuer, it is guaranteed to the merchant, regardless of whether the Issuer or accountholder participates in SecureCode.

The merchant populates the first SecureCode transaction as they do any SecureCode transaction.




Processing Requirements for Merchants Using International Maestro and the Maestro Advanced Registration Program or the MasterCard Advanced Registration Program (MARP), (Continued)

Fully Authenticated Transactions For the first transaction that is fully authenticated, the merchant populates:

1. Transaction Type field with "5" (ECI Indicator – Secure Electronic Commerce Transaction), and

2. AAV field with what was returned at authentication. Attempted Authentication Transactions For the first transaction that is an attempted authentication, the merchant populates:

1. Transaction Type field with "6" (ECI Indicator – Non-Authenticated Electronic Commerce Transaction), and

2. AAV field with value returned from Issuer. If the first International Maestro or MasterCard e-commerce transaction for the accountholder who has registered with the merchant is authorized by the Issuer, the merchant can skip the SecureCode authentication on subsequent transactions by the same customer using the same International Maestro or MasterCard account. Subsequent Transactions For subsequent transactions, the merchant populates:

1. Transaction Type Field with "5" (ECI Indicator – Secure Electronic Commerce Transaction), and

2. AAV field with the assigned static AAV. If a registered accountholder uses a different International Maestro or MasterCard account for a transaction, the merchant must request SecureCode authentication before submitting the transaction for authorization. The merchant always has the option of requesting SecureCode authentication for any International Maestro transaction, in which case the transaction is governed by Maestro rules. If the transaction is subsequently authorized by the Issuer, it is guaranteed to the acquirer or its merchant, regardless of whether the Issuer or accountholder participates in SecureCode as determined by the merchant request.

Issuers may chargeback transactions that are processed using the static AAV.




Maestro Recurring Payments Program (MRPP)

If a European merchant is using International Maestro (IM) and is participating in MARP, they are automatically registered in the Maestro Recurring Payments Program (MRPP). MRPP allows enrolled merchants to accept recurring payments for Maestro e-commerce transactions that have been previously attempted or fully authenticated with SecureCode.

If a merchant wants to participate in MRPP and is not participating in MARP, the merchant must contact their Merchant Services Representative to be enabled for MARP and MRPP. The same rules apply to MRPP as outlined in the Processing Requirements for Merchants Using International Maestro and the Maestro Advanced Registration Program or the MasterCard Advanced Registration Program (MARP) section of this appendix. MRPP is only applicable to recurring transactions using static AAVs.





The merchant must install a certified 3-D Secure Merchant Plug-in software application.

The merchant must verify that Merchant Plug-in provides AAV in Base 64 encoding. If not, the merchant must convert to Base 64 before sending to Merchant Services.

In the settlement of a MasterCard SecureCode transaction, merchants are strongly encouraged to submit the MasterCard Authentication Extension Record. In the event that Merchant Services has to perform a new authorization, the authentication data (AAV) is included in the new authorization. By doing so, the merchant maintains the MasterCard SecureCode chargeback liability shift for authenticated transactions.

Merchants must map the MasterCard Electronic Commerce Indicator (ECI) they receive via their MPI to the appropriate Merchant Services Transaction Type:

Transaction Description

MasterCard ECI Returned in MPI

Merchant Services Transaction Type

Fully Authenticated 02 5

Attempted Authentication

01 6

Authentication Failed or Not Available

No ECI returned 7

Merchants must test and certify with Merchant Services to become MasterCard SecureCode enabled.




Merchant Guidelines (Excludes MARP and MRPP)

Merchants are required to request authorization for all SecureCode e-Commerce transactions.

For International Maestro, it is highly recommended that merchants send SecureCode for e-Commerce transactions.

Merchants must supply the AAV on all authorization attempts.

Initial SecureCode authorization requests with AAVs older than 30 calendar days may be declined by the Issuer.

Subsequent authorization attempts must include the AAV.

Recurring payments should include AAV data for the initial authorization request only. Merchants must not provide authentication data in recurring payment authorizations as these are not considered electronic commerce transactions by MasterCard and subsequently are not eligible for MasterCard SecureCode processing.




Transaction Types and Requirements for MasterCard

MasterCard Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = MC or MR

c. Transaction Type = 5, 6, or 7

2. Format Indicator

a. MasterCard Authentication (MA)

Response:


Batch Request:


a. Action Code = AU

b. MOP = MC or MR


2. Extension Record

a. MasterCard Authentication (EMC002)

Response:





Transaction Types and Requirements for MasterCard, (Continued)

MasterCard Conditional Deposit deposits this transaction ONLY if a valid authorization is obtained.

Batch Request:


a. Action Code = DC

b. MOP = MC or MR


2. Extension Record


Response:





Transaction Types and Requirements for MasterCard, (Continued)

MasterCard Deposits this transaction REGARDLESS of authorization status.

Batch Request:


a. Action Code = DP

b. MOP = MC or MR


2. Extension Record


Response:





Transaction Types and Requirements for International Maestro

International Maestro Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = IM

c. Transaction Type = 2, 5, 6, or 7

2. Format Indicator


i. Accountholder Authentication Value (AAV)

Note: Should be a static AAV when Transaction Type = 2. If blank, the transaction is processed using Transaction Type = 7.

Response:


Batch Request:


a. Action Code = AU

b. MOP = IM


2. Extension Record

a. International Maestro - MasterCard Authentication (EIM002) i. Accountholder Authentication Value (AAV)


Response:





Transaction Types and Requirements for International Maestro, (Continued)

International Maestro Conditional Deposit deposits this transaction ONLY if a valid authorization is obtained.

Batch Request:


a. Action Code = DC

b. MOP = IM


2. Extension Record

a. International Maestro - MasterCard Authentication (EIM002)



Response:





Transaction Types and Requirements for International Maestro, (Continued)

International Maestro Deposits this transaction REGARDLESS of authorization status.

Batch Request:


a. Action Code = DP

b. MOP = IM


2. Extension Record

a. International Maestro - MasterCard Authentication (EIM002)



Response:



International Maestro, MasterCard / All currencies


MARP – International Maestro, MasterCard (for European merchants only)

MRPP – International Maestro (for recurring transactions by European merchants only)



To Get Started



APPENDIX J: MASTERCARD AND VISA DIGITAL WALLET Introduction Digital wallets typically store consumer payment information (such as

account number) and/or funds to enable the consumer to make payments to merchants. For more information about Digital Wallet identifiers contact your Merchant Services Representative.

How it works MasterCard Staged Digital Wallet A Transaction Division flag must be enabled for either “CPS” or “Self”. The merchant Wallet Identification Number (WID) is also defined on the Transaction Division. Transaction Division Enabled for “CPS” The Transaction Division should be dedicated to processing staged digital wallet transactions. Merchant Services automatically submits the Wallet Identification Number (WID) to MasterCard on every SDWO eligible transaction. The Digital Wallet Format Indicator (DW) and the Product Record: Digital Wallet (PDW001) do not need to be sent on any transaction. Transaction Division Enabled for “Self” Each transaction is identified as using or not using a staged digital wallet by sending the Digital Wallet Format Indicator (DW) and the Product Record: Digital Wallet (PDW001). When the transaction is identified as using a staged digital wallet, Merchant Services submits the Wallet Identification Number (WID) to MasterCard on every SDWO eligible transaction.



APPENDIX J: MASTERCARD AND VISA DIGITAL WALLET, (Continued)

How it Works, (Continued)

MasterPass Digital Wallet MasterPass enabled Merchants (enabled via MasterCard) identify their transactions as MasterPass Digital Wallet by sending in the Digital Wallet Format Indicator (DW) or the Product Record: Digital Wallet (PDW001). The Merchant sends the appropriate wallet indicator value and the MasterPass Digital Wallet ID (WID) provided by MasterCard. Transactions that are submitted by a Merchant enabled with MasterPass, but are not processed by the customer via the MasterPass Wallet option on the merchant website, may also qualify for MasterPass specific incentive rates. These transactions must contain a value of ‘2’ in the Digital Wallet Indicator field and meet other rate qualifications. There are no transaction division enablement requirements.

Visa Checkout Visa Checkout enabled Merchants (enabled by Visa) identify their transactions as Digital Wallet by sending in the Digital Wallet Format Indicator (DW) or the Product Record: Digital Wallet (PDW001). Visa Checkout transactions must contain a value of ‘1’ in the Digital Wallet Indicator field. There are no transaction division enablement requirements.







a. MOP = IM, MC, MR, CR, CZ, VI, or VR

b. Action Code = AU

2. Format Indicator

a. Digital Wallet (DW)

i. MasterPass Digital Wallet ID (WID) – MasterPass only

Response:



a. Action Code = AU

b. MOP = IM, MC, MR, CR, CZ, VI, or VR

2. Product Record

a. Digital Wallet (PDW001)


Response:






Deposits this transaction REGARDLESS of authorization status.

Batch Request:


a. Action Code = DP


2. Product Record



Response:






Refund adds amount to the balance. Batch Request:


a. Action Code = RF


2. Product Record,



Response:






International Maestro, MasterCard, Visa / All currencies

ChaseNet / U.S. currency






APPENDIX K: EUROPEAN DIRECT DEBIT Introduction European Direct Debit is a popular method of payment for merchants

marketing in Europe. While any merchant may want to accept direct debit payments, it is most important and cost effective for those merchants collecting recurring payments. Unlike the US, many European customers prefer to pay for recurring services by direct debit to their bank accounts. This is especially true in Germany where almost 40% of all electronic payments are made by direct debit.

How It Works In Europe, each country operates its own direct debit network. Merchant

Services has created a single technical interface for direct debit processing for multiple countries. There are two governing bodies responsible for direct debit standards.

• Bacs (originally Bankers Automated Clearing Services) via the Bacs “Automated Direct Debit Instruction Service” (AUDDIS) – UK only

• European Payments Council (EPC) via the Single Euro Payments Area (SEPA) network – all other supported countries

AUDDIS Within AUDDIS the British “Basic Bank Account Number” (BBAN) structure is supported. The International Bank Account Number (IBAN) and Bank Identifier Code (BIC) are not supported.

SEPA SEPA supports the International Bank Account Number (IBAN) and Bank Identifier Code (BIC) structure. If a non- IBAN account number, Bank Sort Code, Bank Branch Code and/or RIB are sent, Merchant Services converts the account number to an IBAN for processing.

If an IBAN account number is sent inbound, IBAN information is always returned.

If a non-IBAN account number is sent inbound and can be converted to an IBAN account number, a Transaction Division flag can be enabled to always return the IBAN information.

The IBAN information is located in the European Direct Debit 2 Reply Format Indicator (E2) or Extension Record: European Direct Debit (EED001).

When an issuing bank cannot accept electronic deposits or refunds, the transaction rejects with Response Reason Code 747 (Electronic Deposits/ Refunds Not Supported).

A mandate is defined as an agreement between the consumer and merchant to allow the consumer’s direct debit account to be debited in an automated manner over a period of time. The mandate needs to be provided to the consumer’s issuing bank (by the consumer merchant) before the first direct debit occurs. A mandate is a legal document. Its format is country specific.



APPENDIX K: EUROPEAN DIRECT DEBIT (Continued)


When Country Code does not equal GB Validation (Action Code = LO) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Convert and validate account number to IBAN • Validates against an internal negative file • Sends response to merchant

Validation (Action Code = LO) with IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates the IBAN information • Sends response to merchant

Validation and Deposit (Action Code = DO) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Convert and validate account number to IBAN • Validates against an internal negative file • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for deposit

Validation and Deposit (Action Code = DO) with IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates the IBAN information • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for deposit





Validation and Refund (Action Code = ER) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Convert and validate account number to IBAN • Validates against an internal negative file • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for refund

Validation and Refund (Action Code = ER) with IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates the IBAN information • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for refund





When Country Code equals GB Validation (Action Code = LO) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates account number • Sends response to merchant

Validation and Deposit (Action Code = DO) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates account number • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for deposit Validation and Refund (Action Code = ER) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates against an internal negative file • Validates account number • Sends response to merchant • If the transaction successfully passes these steps it is forwarded

for refund Validation and Forward Mandate Information (Action Code = ND) with Non-IBAN Account Number Merchant Services performs the following steps:

• Front end edits for data integrity • Validates the Mandate Type, Mandate ID, and Signature Date are

present • Validates against an internal negative file • Validates the account number • Sends response to merchant • If the transaction successfully passes these steps it is forwarded




Processing Requirements

Merchants must contract with Merchant Services for acceptance of European Direct Debit.

The Currency Code and Country Code of the transaction must correspond appropriately, or the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Examples:

Currency Code = 826 and Country Code = GB

Currency Code = 978 and Country Code = NL

Currency Code = 978 and Country Code = DE




Transaction Types and Requirements for Non-IBAN

Validate Only validates and converts this transaction to IBAN. Conversion is not applicable when Country Code = GB. Online Request:


a. Account Number = 1-16 byte account number

b. Action Code = LO

c. MOP = ED

d. Amount = all zeros

2. Format Indicator

a. European Direct Debit 2 or European Direct Debit (E2 or ED)

i. Country Code

ii. Bank Sort Code (Optional)

iii. RIB Code (Optional)

iv. Bank Branch Code (Optional)

Response:



a. European Direct Debit 2 (E2) (Optional)




Transaction Types and Requirements for Non-IBAN, (Continued)

Validate Only, (Continued) Batch Request:



b. Action Code = LO

c. MOP = ED


2. Extension Record

a. European Direct Debit (EED001)

i. Country Code




Response:


2. Extension Record

a. European Direct Debit (EED001) (Optional)

i. IBAN

ii. BIC

Note: Mandate information is echoed back.





Validate and Deposit validates, converts to IBAN, and deposits this transaction. Conversion is not applicable when Country Code = GB. Batch Request:



b. Action Code = DO

c. MOP = ED

2. Extension Record


i. Country Code




v. Mandate Type (Optional)

vi. Mandate ID (Optional)

vii. Signature Date (Optional)

3. Address Record

a. Address Record: ECP and European Direct Debit (AM or KA)

i. Name Text

Response:


2. Extension Record


i. IBAN

ii. BIC

iii. Mandate Type

iv. Mandate ID

v. Signature Date





Validate and Refund validates, converts to IBAN, and refunds this transaction. Conversion is not applicable when Country Code = GB. Batch Request:



b. Action Code = ER

c. MOP = ED

2. Extension Record


i. Country Code




3. Address Record


i. Name Text

Response:


2. Extension Record


i. IBAN ii. BIC





Transaction Types and Requirements for non- IBAN, (Continued)

Validate and Forward Mandate Information validates and forwards mandate information. Only applicable when Country Code = GB. Batch Request:



b. Action Code = ND

2. Extension Record


i. Country Code

ii. Bank Sort Code

iii. Mandate Type

iv. Mandate ID

v. Signature Date

3. Address Record


i. Name Text

Response:


2. Extension Record





Transaction Types and Requirements for IBAN

Validate Only validates this transaction; not applicable when Country Code = GB. Online Request:


a. Account Number = IBAN

b. Action Code = LO

c. MOP = ED


2. Format Indicator

a. European Direct Debit 2 (E2)

i. Country Code

ii. IBAN

iii. BIC

Response:



a. European Direct Debit 2 (E2)




Transaction Types and Requirements for IBAN, (Continued)

Validate Only (Continued) Batch Request:



b. Action Code = LO

c. MOP = ED


2. Extension Records


i. Country Code

ii. IBAN

iii. BIC

Response:


2. Extension Record


i. IBAN

ii. BIC






Validate and Deposit validates and deposits this transaction; not applicable when Country Code = GB. Batch Request:



b. Action Code = DO

c. MOP = ED

2. Extension Record


i. Country Code

ii. IBAN

iii. BIC

iv. Mandate Type (Optional)

v. Mandate ID (Optional)

vi. Signature Date (Optional)

3. Address Record


i. Name Text

Response:


2. Extension Record






Validate and Refund validates and refunds this transaction; not applicable when Country Code = GB. Batch Request:



b. Action Code = ER

c. MOP = ED

2. Extension Record


i. Country Code

ii. IBAN

iii. BIC

3. Address Record


i. Name Text

Response:


2. Extension Record


i. IBAN ii. BIC






European Direct Debit / Euro and British Pound



To Get Started



APPENDIX L: DEBIT PROCESSING Introduction Accountholders can use their ATM/Debit cards to pay for goods or services

rather than cash, check, or credit card.

Debit transactions are always authorized on a "real-time" basis with the actual authorization resulting in the debit (credit if a refund/reversal transaction) of the accountholder's bank account. Merchants must submit a deposit file to Merchant Services to support funding, reporting, and associated reconciliation. Merchant Services has connectivity to most of the major debit networks in the U.S.

Merchant Services offers two types of Debit processing: PIN-Based and PINless.

Merchants are encouraged to retrieve the appropriate Debit BIN file to determine eligibility for an account for every transaction, including prior to the submission of every recurring transaction, unless the merchant is enabled for Merchant Services’ BINless File Management Product.

Authorizations and Deposits

The purpose of PIN-Based or PINless debit authorizations and deposits is to debit funds from the account of the accountholder.

Debit authorizations and deposits are reported in a separate section of the same reports as other debit transactions.

Debit authorizations and deposits have specific rules, edits, and Response Reason Codes, details of which are provided in the sections below.

Authorizations and Deposits: How It Works

In order for a merchant to use the debit deposit functionality, the merchant must send a successful PA (Purchase Authorization) prior to sending in the deposit request.

Refunds The purpose of PIN-Based or PINless debit refunds is to return funds to the

account of the accountholder, which had been debited by the original debit transaction.

Debit refunds are reported in a separate section of the same reports as other debit transactions. PIN-Based debit refunds must be sent "real-time". PINless debit refunds can be sent in "real-time" or in a batch submission.

Refunds: How It Works

In order for a merchant to use the debit refund functionality, the merchant must send a successful RA (Refund Authorization) prior to sending in the refund request.



APPENDIX L: DEBIT PROCESSING (Continued)

Reversals Merchant initiated PIN-Based and PINless debit reversals are also referred to as merchant voids, cancellations or corrections. The purpose of PIN-Based or PINless debit reversals is to reverse a previous action (i.e. Purchase Authorization or Refund Authorization).

Debit reversals are reported in a separate section of the same reports as other debit transactions. PIN-Based debit reversals must be sent real-time. PINless debit reversals can be sent in "real-time" or in a batch submission.

Reversals: How It Works

In order for a merchant to use the PINless Debit reversal functionality:

1. A merchant must always reverse the full amount of the original debit transaction.

2. The PINless debit reversal should be done in the same manner as the debit transaction, batch or online.

3. A merchant initiated PINless debit reversal must be submitted within 90 minutes of the original debit transaction or the transaction rejects with Response Reason Code 305 (Already Reversed/ Nothing to Reverse). There is an exception for transactions submitted between 20:30 and 22:00 ET. These transactions must be reversed before 22:00 ET.

4. Any PINless debit reversal that fails and cannot be resubmitted within the time limit must be submitted as a debit adjustment.

5. The order number on the reversal must be the same as the order number on the original debit transaction.

In order for a merchant to use the PIN-Based Debit reversal functionality:

1. A merchant must always reverse the full amount of the original debit transaction.

2. A merchant initiated PIN-Based debit reversal must be submitted within 90 minutes of the original debit transaction or the transaction rejects with Response Reason Code 305 (Already Reversed/ Nothing to Reverse). There is an exception for transactions submitted between 20:30 and 22:00 ET. These transactions must be reversed before 22:00 ET.

3. Any PIN-Based debit reversal that fails and cannot be resubmitted within the time limit must be submitted as a debit adjustment.

4. The order number on the reversal must be the same as the order number on the original debit transaction.




Debit Routing Debit Card Routing refers to the decision process that determines which Debit Network to route a particular debit transaction.

Debit Routing: How It Works

Merchant Services offers the following debit routing products. Message Based Routing: This routing product allows merchants to designate a debit sponsor. The host can accept a network identifier in the inbound authorization request and route accordingly. The debit network sponsor is indicated by using one of the following:

• Debit Routing Format Indicator (DR). • Product Record: Debit (PDE001)

Merchant Routing: This routing product uses a merchant provided custom debit sponsor list that is used to determine routing order. Dynamic Debit Routing: This routing product uses a combination of Volume Managed Routing and Cost Based Routing. When combined, Volume Management Routing is used first to target networks where a merchant has volume commitments. Once volume commitments have been met, the host dynamically switches to Cost Based routing. These components can also be decoupled and used as a single solution as described below.

Cost Based Routing: For this product, the expected total cost of each eligible debit network is calculated prior to the authorization and the network with the lowest predicted cost is selected. As with all transactions, the actual total cost of the transaction can only be calculated after the transaction has been completed. The Cost Based Routing method only applies to Authorization Request, Pre-Authorization Request and Return transaction types.

Volume Managed Routing: This product allows for a prioritized list of debit sponsor with volumes amount targets based on either a number of transactions or dollar amounts. The targets and network priorities are set by the merchants and are valid for the entire month and can be added, deleted, or modified at any time throughout the month.

With Volume Managed Routing, eligible transactions are routed to the highest priority sponsor until the volume target is reached. Only authorization approvals, pre-authorization completions, and partial authorization approvals contribute to volume commitments. All transactions that have been routed to a preferred network contribute to the totals regardless of the routing rule used and whether or not the volume commitment has been met or not.




Debit Routing: How It Works, (Continued)

Chase Commerce Solutions Directed Routing: This routing product uses a static routing table of debit sponsors that are referenced to determine appropriate transaction routing. The table is based on the transaction sales amount, MCC, and regulated/exempt status. If no other debit routing products are selected, this is the default method.

Debit Routing: Merchant Requirements

The following debit routing products all require the merchant to enroll in the product and be boarded:

• Merchant Routing • Dynamic Debit Routing • Volume Managed Routing • Cost Based Routing




PINless Debit PINless Debit is more commonly known as Debit Bill Payment, a debit transaction where neither the magnetic stripe contents nor the PIN is part of the authorization message.

Merchant Services currently supports PINless Debit on the four largest debit networks: Star, NYCE, Pulse, and Accel.

The debit network rules for PINless debit programs are strict and the networks that support these transactions must approve the merchant prior to their accepting PINless debit transactions. As a result, PINless debit processing is only available to merchants in select industries.

The debit network must approve and add all payment channels used by the merchant on their system before transactions can be submitted. If a new PINless debit payment channel needs to be added (Call Center, IVR, Web, and Recurring), please contact your Merchant Services Representative for information and registration requirements.

Visa regulations require the consumer be given the opportunity to “opt-out” of having their debit card processed over an alternative network. It allows the merchant to address the consumer choice requirement during the account entry process. Refer to the Debit Bill Payment User Manual for card association and debit network regulations.




PINless Debit Transaction Types

The following charts list the transaction types that can be sent in an online or batch transaction. Transaction Types – Online

Action Code Method of Payment

Valid Transaction Types Note: All non-valid transaction types reject with Response Reason Code 253 (Invalid Transaction Type).

PA (Purchase Authorization)

DP (Generic PINless Debit MOP)

1 – MOTO (Telephone Order only) 2 – Recurring 7 – Internet I – IVR

PR (Purchase Authorization Reversal)

Any PINless Debit MOP


RA (Refund Authorization)



DR (Refund Authorization Reversal)






PINless Debit Transaction Types, (Continued)

Transaction Types – Batch Action Code Method of Payment Valid Transaction Types

Note: All non-valid transaction types reject with Response Reason Code 253 (Invalid Transaction Type).



2 – Recurring



2 – Recurring

DP (Deposit) Specific MOP of Debit Network used for the authorization Example: AP – Accel PINless NP – NYCE PINless PP – Pulse PINless SP – Star PINless


DC (Conditional Deposit)


2 – Recurring



2 – Recurring



2 – Recurring

RF (Refund) Specific MOP of Debit Network used for the refund authorization Example: AP – Accel PINless NP – NYCE PINless PP – Pulse PINless SP – Star PINless





PINless Debit Transaction Matching Criteria

The following charts identify the duplicate purchase and refund authorization detection process.

Matching for Purchase Authorization (PA) and Refund Authorization (RA) using Account Number, Amount, Division Number, and Order Number Processing Mode

Matching Result Action Taken

Online and Batch

No Match Found Transaction is sent to Debit Network for authorization.

Online and Batch

Match Found Response Reason Code 109 (Previously Processed Transaction) is returned. Transaction is not re-authorized with Debit Network. Method of Payment from the original transaction is returned. Trace Number and/or Biller Reference Number are echoed back.

Matching for Conditional Deposit (DC) uses Account Number, Amount, Division Number, and Order Number Processing Mode


Batch Match found as already deposited in Duplicate Database (Stratus Duplicate File).

Response Reason Code 264 (Duplicate Deposit Transaction) is returned. Transaction is not processed.

Batch No Match Found or Match Found in Debit Awaiting Deposit (DAD) Database as already deposited.

Transaction is sent to Debit Network for authorization. If approved, transaction is deposited.

Batch Match Found in Debit Awaiting Deposit (DAD) Database as not deposited.

Response Reason Code 109 (Previously Processed Transaction) is returned. Transaction is not re-authorized with Debit Network. Transaction is deposited.




PINless Debit Transaction Matching Criteria, (Continued)

The following charts identify the matching and validation processes. Both matching and validation must be successful for a transaction to deposit or refund.

Matching for Purchase Authorization (PA) to Deposit (DP) and Refund Authorization (RA) to Refund (RF) uses Trace Number, Account Number, and Division Number. Processing Mode


Batch No Match Found Response Reason Code 740 (Match Failed) is returned. Transaction is not deposited.

Batch Match Found Check for prior order validation.

Validation for Purchase Authorization (PA) to Deposit (DP) and Refund Authorization (RA) to Refund (RF) uses Trace Number, Account Number, Division Number, Amount, MOP returned from Authorization, and complimentary Action Code. Processing Mode


Batch No Match Found Response Reason Code 741 (Validation Failed) is returned. Transaction is not deposited.

Batch Match Found Response Reason Code 100 (Approved) is returned. Transaction is deposited.




PINless Debit Transaction Types and Requirements

Purchase Authorization verifies customer’s open-to-buy and if the funds are available, debits the customer’s account. Online Request:


a. Action Code = PA

b. MOP = Any generic PINless Debit MOP

2. Format Indicator

a. Order Information 2 (O2)

Response:



a. Debit (DB)

i. Trace Number

Batch Request:


a. Action Code = PA

b. MOP = Any PINless Debit MOP

c. Authorization/Verification Code = blanks

2. Product Record

a. Debit (PDE001) i. Trace Number = blanks ii. Biller Reference Number

Response:


2. Product Record

a. Debit (PDE001)

i. Trace Number




PINless Debit Transaction Types and Requirements, (Continued)

Purchase Authorization Reversal reverses the previously attempted or approved purchase authorization. Online Request:


a. Action Code = PR


c. Amount = Original, authorized amount.

d. Merchant Order Number = Original order number from purchase authorization



b. Prior Authorization (PA) or Prior Authorization and Reversal Reason Format Indicator (P4) (Optional)

i. Debit Trace Number

Response:



a. Debit (DB)

i. Trace Number





Purchase Authorization Reversal, (Continued) Batch Request:


a. Action Code = PR



d. Response Date = Original, authorized date or blank.

e. Authorization Code = Original, authorization code or blank.

f. Merchant Order Number = Original order number from purchase authorization

2. Product Record

a. Debit (PDE001) i. Biller Reference Number

Response:


2. Product Record

a. Debit (PDE001)

i. Trace Number





Deposit funds the merchant for the previously approved purchase authorization. Batch Request:


a. Action Code = DP

b. MOP = PINless Debit MOP returned at time of purchase authorization

2. Product Record

a. Debit (PDE001)

i. Trace Number

Response:






Refund Authorization returns funds to the customer for a previously approved debit purchase authorization. Online Request:


a. Action Code = RA

b. MOP = DE or DP

2. Format Indicator


Response:



a. Debit Reply Format Indicator (DB)

i. Trace Number

Batch Request:


a. Action Code = RA


c. Authorization/Verification Code = blanks

2. Product Record

a. Debit (PDE001)

i. Trace Number = blanks ii. Biller Reference Number

Response:


2. Product Record

a. Debit (PDE001)

i. Trace Number Continued on next page




Refund Authorization Reversal reverses the previously attempted or approved refund authorization. Online Request:

1. Online Processing Detail Record a. Action Code = DR b. MOP = Any PINless Debit MOP c. Amount = Original, refund authorization amount. d. Merchant Order Number = Original order number from refund

authorization 2. Format Indicators

a. Order Information 2 (O2) b. Prior Authorization (PA) or Prior Authorization and Reversal

Reason Format Indicator (P4) (Optional) i. Debit Trace Number

Response: 1. Online Processing Return Format Record 2. Reply Format Indicator

a. Debit Reply Format Indicator (DB) i. Trace Number

Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = DR b. MOP = Any PINless Debit MOP c. Merchant Order Number = Original order number from refund

authorization 2. Product Record

a. Debit (PDE001) i. Biller Reference Number

Response: 1. "S" Record Output 2. Product Record

a. Debit (PDE001) i. Trace Number





Refund removes the funds from the merchant for the previously approved refund authorization. Batch Request:


a. Action Code = RF

b. MOP = PINless Debit MOP returned at time of refund authorization

2. Product Record

a. Debit (PDE001)

i. Trace Number

Response:






Conditional Deposit verifies customer’s open-to-buy and if the funds are available, debits the customer’s account and funds the merchant.

Batch Request:


a. Action Code = DC

b. MOP = Generic PINless Debit MOP

c. Transaction Type = 2

d. Authorization/Verification Code = Blanks

2. Product Record

a. Debit (PDE001) i. Trace Number = blanks ii. Biller Reference Number

Response:


2. Product Record

a. Debit (PDE001)

i. Trace Number




PIN-Based Debit and EBT

A PIN-Based Debit transaction is when the card is swiped at the point of sale (POS) and the accountholder keys the Personal Identification Number (PIN). The PIN pad encrypts the PIN before it is sent for processing.

Network and federal regulations require the accountholder be provided with a receipt of the debit transaction, if approved.

Merchants must have their POS terminal configured with a PIN pad that has payment encryption keys set up by a TG-3 compliant and Merchant Services approved Encryption Service Organization (ESO). Electronic Benefits Transfer (EBT) transactions are processed as PIN-Based Debit transactions.

PIN-Based Debit and EBT Transaction Types

The following charts list the transaction types that can be sent in an online or batch transaction.

Transaction Types – Online Action Code Method of Payment Valid Transaction Types

Note: All non-valid transaction types reject with Response Reason Code 253 (Invalid Transaction Type).


DE (Generic PIN-Based Debit MOP) or EB

R – Retail


Any PIN-Based Debit MOP or EB

R – Retail


DE (Generic PIN-Based Debit MOP) or EB

R – Retail


Any PIN-Based Debit MOP or EB

R – Retail

BI (Current Balance Inquiry)

EB R – Retail

PC (Prior Voice Authorization Completion)

EB R – Retail




PIN-Based Debit Transaction Types, (Continued)

Transaction Types - Batch Action Code

Method of Payment Valid Transaction Types Note: All non-valid transaction types reject with Response Reason Code 253 (Invalid Transaction Type).

DP (Deposit) Specific MOP of Debit Network used for the authorization or EB.

Examples: NY – NYCE PIN-Based Debit

PS – Pulse PIN-Based Debit

SR – Star PIN-Based Debit

EB – Electronic Benefits Transfer

R – Retail

RF (Refund) Specific MOP of Debit Network used for the refund authorization or EB.

Examples: NY – NYCE PIN-Based Debit

PS – Pulse PIN-Based Debit

SR – Star PIN-Based Debit

EB – Electronic Benefits Transfer

R – Retail




PIN-Based Debit Transaction Matching Criteria

The following chart identifies the duplicate purchase and refund authorization detection process. Matching for Purchase Authorization (PA) and Refund Authorization (RA) uses Account Number, Amount, Division Number, and Order Number Processing Mode


Online

No Match Found Transaction is sent to Debit Network for authorization.

Online Match Found Response Reason Code 109 (Previously Processed Transaction) is returned. Transaction is not re-authorized with Debit Network. Method of Payment from the original transaction is returned. Trace Number and/or Biller Reference Number are echoed back.

The following charts identify the matching and validation processes. Both matching and validation must be successful for a transaction to deposit or refund.

Matching for Purchase Authorization (PA) to Deposit (DP) and Refund Authorization (RA) to Refund (RF) uses Trace Number, Account Number, and Division Number. Processing Mode



Batch Match Found Check for prior order validation.




PIN-Based Debit Transaction Matching Criteria, (Continued)

Validation for Purchase Authorization (PA) to Deposit (DP) and Refund Authorization (RA) to Refund (RF) uses Trace Number, Account Number, Division Number, Amount, MOP returned from Authorization, and complimentary Action Code. Processing Mode


Batch No Match Found Response Reason Code 741 (Validation Failed) is returned.

Transaction is not deposited.

Batch Match Found Response Reason Code 100 (Approved) is returned.

Transaction is deposited.




PIN-Based Debit and EBT Transaction Types and Requirements

Purchase Authorization verifies customer’s open-to-buy and if the funds are available, debits the customer’s account. Online Request:


a. Action Code = PA

b. MOP = Any generic PIN-Based Debit MOP or EB





c. Electronic Benefits Transfer (EBT) (Optional)

Note: Required when MOP = EB

Response:



a. Debit (DB)

i. Trace Number

b. Electronic Benefits Transfer (EBT) (Optional)

Note: Returned when MOP = EB




PIN-Based Debit and EBT Transaction Types and Requirements, (Continued)

Purchase Authorization Reversal reverses the previously attempted or approved purchase authorization. Online Request:


a. Action Code = PR

b. MOP = Any generic PIN-Based Debit MOP or EB





b. Retail (RE) or Retail 3 (R3) (Optional) Note: Track 2 data must be sent if this Format Indicator is used.

c. Electronic Benefits Transfer (EBT) (Optional) Note: Required when MOP = EB

Response:



a. Debit (DB)

i. Trace Number









a. Action Code = DP

b. MOP = PIN-Based Debit MOP returned at time of purchase authorization or EB

2. Product Record

a. Debit (PDE001)

i. Trace Number ii. Account Type (Optional)


Response:






Refund Authorization returns funds to the customer for a previously approved debit purchase authorization. Online Request:


a. Action Code = RA

b. MOP = DE or EB



b. Retail (RE) or Retail 3 (R3) (Optional)

Note: Track 2 data must be sent if this Format Indicator is used.


Notes: Required when MOP = EB Refunds should only be sent for Food Stamps

Response:




i. Trace Number

b. Electronic Benefits Transfer (EBT) (Optional) Note: Required when MOP = EB





Refund Authorization Reversal reverses the previously attempted or approved refund authorization. Online Request:

1. Online Processing Detail Record a. Action Code = DR b. MOP = Any PIN-Based Debit MOP or EB c. Amount = Original, refund authorization amount. d. Merchant Order Number = Original order number from refund

authorization 2. Format Indicators

a. Debit Information (DB) b. Retail (RE) or Retail 3 (R3) (Optional)

Note: Track 2 data must be sent if this Format Indicator is used.


Note: Required when MOP = EB Response:

1. Online Processing Return Format Record 2. Reply Format Indicators

a. Debit Reply Format Indicator (DB) i. Trace Number







Refund removes the funds from the merchant for the previously approved refund authorization. Batch Request:


a. Action Code = RF

b. MOP = PIN-Based Debit MOP returned at time of refund authorization or EB

2. Product Record

a. Debit (PDE001)

i. Trace Number ii. Account Type (Optional)


Response:





PIN-Based Debit for EBT Only Transaction Types and Requirements

Balance Inquiry obtains the current balance for an Electronic Benefits Transfer account. Online Request:


a. Action Code = BI

b. MOP = EB

c. Amount = All zeros





c. Electronic Benefits Transfer (EBT)

Response:



a. Debit (DB)

i. Trace Number

b. Electronic Benefits Transfer (EBT)




PIN-Based Debit for EBT Only Transaction Types and Requirements, (Continued)

Prior Voice Authorization Completion verifies a previous voice authorization for an Electronic Benefits Transfer transaction. Online Request:


a. Action Code = PC

b. MOP = EB

c. Amount = Amount of previous voice authorization


a. Debit Information (DB) (Optional)




d. Prior Authorization (PA)

i. Authorization Code

Response:



a. Debit (DB)

i. Trace Number







PINless BIN File Management

PINless BIN File Management removes the merchant’s burden of maintaining a separate BIN file for PINless transactions. Merchant Services manages the PINless BIN file on behalf of the merchant.

PINless BIN File Management allows merchants to send transactions with debit and credit attributes and Merchant Services determines if the transaction is processed as debit, MasterCard, or Visa.

Merchants should contact their Merchant Services Representative to be enabled for PINless BIN File Management.

PINless BIN File Management: How It Works

During the consumer payment session, the merchant asks the consumer if the card is a debit card. If the consumer identifies the card as a debit card, the merchant gathers all the necessary transaction information used for credit and debit processing. The merchant submits the transaction with credit and debit attributes. Merchant Services checks the following eligibility parameters to determine if the transaction should be processed as PINless debit:

• BIN is eligible

• MCC is eligible

• Division is enabled for debit processing

If the transaction cannot be processed as PINless debit, the transaction may be routed to MasterCard or Visa.

If the merchant submits a valid transaction, but the BIN cannot be processed as PINless debit, MasterCard, or Visa, the transaction rejects with Response Reason Code 742 (Unable to Process Transaction as Debit or Credit).

If the merchant submits a valid transaction, but the MCC cannot be processed as PINless debit, MasterCard, or Visa, the transaction rejects with Response Reason Code 249 (Invalid MCC).




PINless BIN File Management: Sending Transactions

Transactions are sent with both debit and credit attributes. The Generic PINless Debit MOP (DP) is always sent with PINless debit Action Codes.

Address Verification Service (AVS), Card Security Value (CSV), and Expiration Date should be sent to support credit processing. If the transaction is processed as debit, the specific debit network MOP is returned in the response.

If the transaction is processed as credit, MasterCard or Visa MOP is returned in the response.

The following chart identifies how transactions are processed using PINless BIN File Management.

Allowable Action

Code to be Sent

MOP Sent

Returned MOP if

Processed as Debit

Returned MOP if

Processed as Credit

Returned Action Code if

Processed as Debit

Returned Action Code if

Processed as Credit

PA DP AP, NP, PP, SP

MC, VI PA AU

PR DP AP, NP, PP, SP

MC, VI PR AR

DC DP AP, NP, PP, SP

MC, VI DC DC

When sending reversal transactions, if the original authorization was processed as a credit transaction, the reversal should be sent as a credit reversal. Please see Appendix F: Authorization Reversals for more information.

Deposit transactions must be sent using the specific deposit attributes that correspond with how the authorization was processed. For example: if authorized as a credit transaction, deposit as a credit transaction.

Transaction Type must =1, 2, 7, or I or the transaction rejects with Response Reason Code 253 (Invalid Transaction Type).

If sent with Transaction Type = I and processed as credit, the transaction rejects with Response Reason Code 225 (Invalid Field Data).The Transaction Type on the credit card deposit transaction must be a valid credit card transaction type.

Refunds are not supported with PINless BIN File Management.




PINless BIN File Management Transaction Types and Requirements

Purchase Authorization, if processed as debit, verifies customer’s open-to-buy and if the funds are available, debits the customer’s account. If processed as credit, verifies the accountholder's open-to-buy and reserves it. Online Request:


a. Action Code = PA

b. MOP = DP

c. Expiration Date (Optional)


a. Bill to Address (AB) (Optional)

b. Postal Code Only Address (AZ) (Optional)

c. Fraud (FR) (Optional)

d. Formatted Bill to Name (LN) (Optional)

e. Order Information 2 (O2) (PINless Debit only)

f. Partial Authorization (PB) (Optional)

Response:


a. MOP =

i. Specific PINless Debit Network MOP if processed as debit

ii. MC if processed as credit

iii. VI if processed as credit

b. AVS Response Code if processed as credit (Optional)

c. Card Security Value Response Code if processed as credit (Optional)


a. Debit Reply Format Indicator (DB) – If processed as debit (Optional)

i. Trace Number





PINless BIN File Management Transaction Types and Requirements, (Continued)

Purchase Authorization, (Continued)

Batch Request:


a. Action Code = PA

b. MOP = DP

c. Expiration Date (Optional)

2. Product Records

a. Fraud (PFR001) (Optional)

b. Debit (PDE001)

i. Trace Number = blanks

c. Partial Authorization (PPB001) (Optional)

3. Address Records (Optional)

a. Bill to Address (AB or LN, LA, and LT)

Response:


a. Action Code =

i. PA if processed as debit

ii. AU if processed as credit

b. MOP =


ii. MC if processed as credit

iii. VI if processed as credit

c. Transaction Type = Value processed with

d. AVS Response Code if processed as credit (Optional)

e. Card Security Value Response Code if processed as credit (Optional)

2. Product Records

a. Debit (PDE001) (Optional)

i. Trace Number

b. Partial Authorization (PPB001) (Optional) Continued on next page




Purchase Authorization Reversal, if processed as debit, reverses the previously attempted or approved purchase authorization.

Note: When sending reversal transactions, if the original authorization was processed as a credit transaction, the reversal should be sent as a credit reversal. Please see Appendix F: Authorization Reversals for more information.

Online Request:


a. Action Code = PR

b. MOP = DP




a. Order Information 2 (O2) (Required for debit reversals)

b. Prior Authorization (PA) or Prior Authorization and Reversal Reason Format Indicator (P4)

i. Debit Trace Number (Optional)

Response:


a. MOP = Specific PINless Debit Network MOP if processed as debit



i. Trace Number





Purchase Authorization Reversal, (Continued) Batch Request:


a. Action Code = PR


c. Amount = Original, authorized amount


2. Product Record

a. Debit (PDE001) (Required for debit reversals) i. Biller Reference Number

Response:


a. Action Code = PR

b. MOP = Specific PINless Debit Network MOP if processed as debit

c. Transaction Type = Value processed with

2. Product Record

a. Debit (PDE001)

i. Trace Number





Conditional Deposit, if processed as debit, verifies customer’s open-to-buy and if the funds are available, debits the customer’s account and funds the merchant. If processed as credit, verifies the accountholder's open-to-buy and debits the customer’s account.

Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = DC b. MOP = DP c. Transaction Type = 2 d. Authorization/Verification Code = Blanks e. Expiration Date (Optional)

2. Product Records a. Debit (PDE001)

i. Trace Number = blanks ii. Biller Reference Number

b. Fraud (PFR001) (Optional) 3. Address Records (Optional)

a. Bill to Address (AB or LN, LA, and LT) Response:

1. "S" Record Output a. Action Code = DC b. MOP =


ii. MC if processed as credit iii. VI if processed as credit

c. Transaction Type = Value processed with d. AVS Response Code if processed as credit (Optional) e. Card Security Value Response Code if processed as credit

(Optional) 2. Product Record

a. Debit (PDE001) if processed as debit (Optional) i. Trace Number





Debit Bill Payment User Manual Appendix T: Soft Merchant Information and Merchant Descriptor


Debit / U.S. Dollar





APPENDIX M: BILL ME LATER Introduction Bill Me Later is an innovative and secure payment solution for card not

present merchants. The Bill Me Later method of payment manages the customer payment function by providing a transactional credit decision in lieu of the standard predetermined credit line and associated authorization process. Bill Me Later allows customers to make online/mail order purchases without inputting credit card information.

How It Works Using proprietary credit scoring and fraud detection capabilities, BillMeLater

screens each Bill Me Later transaction in "real-time", instantly deciding all Bill Me Later requests made by customers.


Merchant must contract with BillMeLater.

BillMeLater recommends that merchants send the following data on ALL Bill Me Later Web authorization transactions:

1. Bill to Address 2. IP Address 3. Email Address 4. Ship to Address 5. Bill Me Later Information 6. Order Information 7. Personal Information

Notes: For fields noted as optional on these records, the absence of this data does not result in a front end reject of the transaction by Merchant Services, but may result in a decline from BillMeLater.

Please contact your BillMeLater Integration Analyst during the requirements definition phase prior to development to determine required fields.



APPENDIX M: BILL ME LATER, (Continued)


Authorization verifies the accountholder's open to buy and reserves it. Online: Request:


a. Action Code = AU

b. Method of Payment = BL

c. Account Number = Customer’s Bill Me Later Account Number or Merchant’s Bill Me Later BIN followed by 10 zeros


a. Bill to Address (AB)

b. IP Address (AI)

c. Email Address (AL)

d. Ship to Address (AS)

e. Bill Me Later (BL) or Bill Me Later Information (BM)

f. Order Information (OI)

g. Personal Information (PI)

Response:


a. Account Number = Customer’s Bill Me Later Account Number (if approved)


a. Bill Me Later (BM) (Optional)





Authorization verifies the accountholder's open to buy and reserves it.

Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the accountholder's account and funds the merchant. Batch: Request:


a. Action Code = AU or DC



2. Extension Record

a. Bill Me Later (EBL001)

3. Information Records

a. Order Information (IOI001)

b. Personal Information (IPI001)

4. Address Records


b. IP Address (AI)



Response:







Deposit funds the merchant from a previously approved authorization.

Refund removes the funds from the merchant for the previously approved deposit.

Batch: Request:


a. Action Code = DP or RF


c. Account Number = Customer’s Bill Me Later Account Number

Response:



Bill Me Later / All currencies



To Get Started



APPENDIX N: BILL ME LATER PRIVATE LABEL Introduction Bill Me Later Private Label is an innovative product that combines the

merchant-focused aspects of a traditional private label program with the revolutionary benefits of Bill Me Later. By enrolling in a Bill Me Later Private Label program, a customer secures a dedicated credit line at their preferred merchant. This means greater utility for the customer and stronger customer loyalty for the merchant.

How It Works Using proprietary credit scoring and fraud detection capabilities, BillMeLater

seamlessly integrates the application into the purchase stream, instantly providing customers with additional buying power at the point-of-sale.


Merchant must contract with BillMeLater.

BillMeLater recommends that merchants send the following data on ALL private label new account transactions:

1. Bill to Address

2. IP Address

3. Email Address

4. Bill Me Later Private Label or Bill Me Later Information (Format Indicator BP or BM)

5. Personal Information

6. Employer Address

BillMeLater recommends that merchants send the following data on authorization transactions:

1. Bill to Address (for Card Not Present)

2. IP Address (for Web transactions)

3. Bill Me Later Private Label Information or Bill Me Later Information (Format Indicator BP or BM)

4. Order Information

5. Fraud Information (for Card Not Present)

6. Retail Swipe Information (for POS)

For fields noted as optional on these records, the absence of this data does not result in a front end edit reject of the transaction by Merchant Services, but could result in a decline from BillMeLater.

Please contact your BillMeLater Integration Analyst during the requirements definition phase prior to development to determine required fields.



APPENDIX N: BILL ME LATER PRIVATE LABEL, (Continued)


Authorization verifies the accountholder's open to buy and reserves it. Online: Request:


a. Action Code = AU

b. Method of Payment = BP

c. Account Number = Merchant’s Bill Me Later BIN followed by 10 zeros



b. IP Address (AI)


d. Bill Me Later Information (BM) or Bill Me Later Private Label (BP)

e. Order Information (OI)

f. Personal Information (PI)

g. Employer Address (AE)

Response:




a. Bill Me Later (BM) or Bill Me Later Private Label (BR)





Authorization verifies the accountholder's open to buy and reserves it.

Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the customer’s account and funds the merchant.

Batch: Request:


a. Action Code = AU or DC



2. Extension Record

a. Bill Me Later (EBL001)

3. Information Records

a. Order Information (IOI)

b. Personal Information (IPI001)

4. Address Records


b. IP Address (AI)



Response:


a. Account Number = Customer’s Bill Me Later Account Number (if approved).






Refund removes the funds from the merchant for the previously approved deposit.

Batch: Request:


a. Action Code = DP or RF


c. Account Number = Customer’s Bill Me Later Account Number

Response:



Bill Me Later Private Label / All currencies



To Get Started



APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION

Introduction With so many high profile data breaches reported in the press and the high cost of maintaining PCI compliance, it is of the utmost importance to protect customer information should a breach occur.

Safetech Page Encryption CNP and Tokenization solves this security issue by allowing card not present merchants to encrypt consumer entered card data during the consumer’s browser session using a one-time key to avoid having access to clear card data. The encrypted data is only valid for the initial authorization. Subsequent transactions or batch uploads require the use of the token returned in the authorization response message. Products that traditionally require a clear account number to be checked against a BIN file follow a different process when using Safetech Page Encryption CNP. The differences for these products are outlined below. If Encryption Flag = 201 or 202, and inbound encrypted account number cannot be decrypted, the transaction rejects with Response Reason Code 282 (Decryption Failure).

If Encryption Flag = 204, and inbound token cannot be decrypted, the transaction rejects with Response Reason Code 282 (Decryption Failure).

When Encryption Flag = 203 and a token cannot be returned, the transaction is processed. The Token ID Reply Format Indicator is not returned. If the transaction is approved (Response Reason Code = 100 (Approved)), a new request using Action Code = TN should be sent to tokenize the account number.

When Encryption Flag = 203 and Action Code = TN and a token cannot be returned, the transaction rejects with Response Reason Code 281 (Token unavailable).



APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued)

Introduction, (Continued)

Level 3 Merchants who want to use Safetech Page Encryption CNP with Level 3 processing need to use Card Type Indicator to determine if the account number is Level 3 capable. Healthcare IIAS Merchants who want to use Safetech Page Encryption CNP with Healthcare IIAS processing need to first perform an account verification (Action Code = VF) with Card Type Indicator to determine if the account number is Healthcare IIAS capable. The returned Token ID is used for all subsequent transactions. PINless Debit Merchants who want to use Safetech Page Encryption CNP with PINless Debit processing need to use Merchant Services’ PINless BIN File Management product and can only use Format Preserving Encryption (FPE). Account Updater It is recommended that merchants who want to use tokenization with Account Updater processing should use a token format of first 6 / last 4. Consumer Directed Payment Token Initial and subsequent transactions submitted with a Safetech Token created from a CDPT must adhere to the same transaction formatting rules as standard CDPT transactions. (i.e., submit all applicable cryptogram data, extension records and product records for CDPT support).

Page Encryption CNP and Tokenization

Merchant Services supports two types of page encryption resulting in a token being returned. This allows card not present merchants to encrypt consumer entered card data during the consumer’s browser session using a one-time key to avoid having access to clear card data. The encrypted data is only valid for the initial authorization. Subsequent transactions or batch uploads requires the use of the token returned in the authorization response message.




Page Encryption CNP and Tokenization, (Continued)

Format Preserving Encryption (FPE) FPE refers to encrypting in such a way that the encrypted account number is the same length as the non-encrypted account number.

Both MOD 10 and non-MOD 10 check digit account numbers are supported.

Example of first 6/last 4 (Format ID = 64): Clear Account Number to Encrypted Account Number 4319021445769876 to 4319026596739876

embedded Format Preserving Encryption (eFPE) eFPE refers to encrypting in such a way that the encrypted account number is 19 bytes in length.

eFPE references the Key ID and Phase ID within the Account Number field. This requires alpha/numeric support and increases the account number to 19 bytes.

Only MOD 10 check digit account numbers are supported.

Example of 16 byte account number using first 6/last 4 (Format ID = 64): Clear Account Number to Encrypted Account Number 1111222233334444 to 111122ijOZ9vCYz4444

Example of 19 byte account number using first 6/last 4 (Format ID = 64): Clear Account Number to Encrypted Account Number 5521423659716800000 to 552142dcnitg6Hr0000

Note: Positions 7 through 15 of the encrypted account number includes the encrypted digits, the Phase ID and the embedded key identifier (not the key itself).

Tokenization The use of FPE and eFPE results in the return of a token that can be used for subsequent transactions.

Account number tokenization can be utilized without page encryption.


The token format is set as a transaction division default.




How It Works – Page Encryption and Tokenization

Safetech Page Encryption allows Card Not Present merchants to encrypt consumer entered card data during the consumer’s browser session using a one-time key to avoid having access to clear card data. The encrypted data is only valid for the initial authorization. Subsequent transactions require the use of the token returned in the authorization response message.

Merchant Services supports token servers in two geographic locations. If a request is returned with Response Reason Code 281 (Token Unavailable) the request should be sent to the alternate server within three days. Two JavaScript files are required for page encryption on the merchant’s Pay Page:

• getkey.js • encryption.js

The steps below detail the process in the test environment. The production environment uses different URLs.

1. When the Pay Page is loaded in the consumer’s browser, prior to any subsequent data entry or other actions taken by the consumer, a one-time dynamic key request is sent to Merchant Services via a request to download the JavaScript getkey.js routine.

Example: https://safetechpageencryptionvar.chasepaymentech.com/pie/v1/XXYYYYYYYYYYYY/getkey.js Where:

XX = Format ID - see Safetech Page Encryption Format Indicator (EI) or the Product Record: Safetech Page Encryption (PEI001) for valid values

YYYYYYYYYYYY = Subscriber ID - unique value assigned by Merchant Services

2. Merchant Services returns the following values to the consumer’s browser from the getkey.js . These are used in the JavaScript encryption.js.

• One-time Key • PIE.key_id • PIE.phase • PIE.L and PIE.E (the combination of these is the Format ID)




How It Works – Page Encryption and Tokenization, (Continued)

3. Once the values for getkey.js are returned, the second JavaScript request (encryption.js) is sent to Merchant Services to obtain a package of Javascript functions including the encryption function, the MOD 10 check digit validation function, and the integrity check value. The JavaScript uses the return values from the getkey.js.

Example: https://safetechpageencryptionvar.chasepaymentech. com/pie/v1/encryption.js

4. The JavaScript encryption package is returned to the consumer’s browser.

5. The consumer enters their card number, card security value, and other payment information using the merchant provided data entry routines and fields. In the code provided by the merchant, prior to allowing a click of the Pay Page submit button, the merchant must invoke the encryption routine using the specified encryption format (returned in number 4 above). The routine returns the encrypted account number, the encrypted CVV, and an integrity check value.

6. The merchant’s payment application sends the encrypted account number, encrypted CVV, as well as other required data to Merchant Services.

7. Merchant Services decrypts the account number and card security

value for processing and returns a token to the merchant’s payment application in the response message. The token can be used for future processing.

Note: The dynamic one-time key is valid for three days. If a transaction is not submitted within three days, Merchant Services cannot decrypt the account number and card security value, and the transaction rejects with Response Reason Code 282 (Decryption Failure). The example URLs above are for test only. The production environment uses different URLs.




Required Fields

The following chart lists the required fields for processing.

Encryption Flag (indicates incoming account number type and expected return value)

Key ID Format ID

Subscriber ID Phase ID Integrity Check

201 = FPE to Token Required Required Required Required Required 202 = eFPE to Token NA (is

embedded in account number)

Required Required NA (is embedded in account number)

Required

203 = Clear to Token

NA NA NA NA NA

204 = Token to same Token

Note: When Action Code = TN, the transaction rejects with Response Reason Code 244 (Invalid Encryption Format)

NA NA NA NA NA




Test and Production URLs

Test System

getkey.js https://safetechpageencryptionvar.chasepaymentech.com/pie/v1/XXYYYYYYYYYYYY/getkey.js encryption.js https://safetechpageencryptionvar.chasepaymentech.com/pie/v1/encryption.js Production System getkey.js https://safetechpageencryption.chasepaymentech.com/pie/v1/ XXYYYYYYYYYYYY /getkey.js

encryption.js https://safetechpageencryption.chasepaymentech.com/pie/v1/encryption.js

Where: XX = Format ID - see Safetech Page Encryption Format Indicator (EI) or the Product Record: Safetech Page Encryption (PEI001) for valid values

YYYYYYYYYYYY = Subscriber ID - unique value assigned by Merchant Services




JavaScript Example - getkey.js

The Merchant Services server returns dynamically generated JavaScript to the browser in response to the JavaScript include on the shopping cart page. The file named getkey.js contains the following five dynamic variables, which contain different values for each request:

• PIE.L - the number of leading digits to remain in the clear. • PIE.E - the number of trailing digits to remain in the clear. • PIE.K – the one-time key used to encrypt the PAN and CVV data. • PIE.key_id - the key ID that corresponds to the key. • PIE.phase - the phase ID

The following shows an example of the results Merchant Services returns to the browser on the “getkey.js” request. These values are used by the static encryption.js file to perform the PIE encryption.

// dynamically-generated values PIE.L = 6; PIE.E = 4; PIE.K = "19d742025e3c78f4a66733569050c68e"; PIE.key_id = "4d8da11f"; PIE.phase = 0;

If getkey.js returns TRUE, the function failed and the above values are not returned. The merchant must make a business decision on how to proceed with the customer order.




JavaScript Example - encryption.js

This static JavaScript file contains MOD 10 check digit validation, encryption, and integrity check functions. This file uses the dynamically generated values from the getkey.js.

The encryption.js contains the following two functions:

1. ValidatePANChecksum - validates if the specified PAN value has a valid MOD 10 checksum, and returns true if it does or false if it doesn't.

The MOD 10 checksum routine included in the encryption.js or the merchant’s own checksum logic is required for eFPE and is optional for FPE.

2. ProtectPANandCVV - performs the PIE encryption on the specified

account number value and card security value.

Merchants identify within this routine whether the account number is encrypted with embedded format preserving (eFPE) or non-embedded format (FPE). This routine always returns either a NULL or zero relative array of 3 values. If a NULL is returned, there was an error encrypting the PAN. The 3 array values returned are: 0 – the encrypted form of the card number 1 – the encrypted form of the CVV 2 – the encrypted form of the Integrity Check value

3. integrityCheck – a value returned from the encryption.js. Returned for both types of encryption ( eFPE and FPE). This value is sent in the Safetech Page Encryption Format Indicator (EI).


© Paymentech, LLC. All rights reserved 447 October 13, 2017

APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued) Test JavaScript Examples – getkey.js and encryption.js <!DOCTYPE html> <html lang="en"> <head> <title>PIE Encryption | Chase Paymentech</title> <meta charset="UTF-8"> <link href="styles/reset-style.css" rel="stylesheet"> <link href="styles/simple.css" rel="stylesheet">  <script type="text/javascript" src="https://safetechpageencryption-dev.salem.paymentech.com/pie/v1/encryption.js"></script> <script type="text/javascript" src="https://safetechpageencryption-dev.salem.paymentech.com/pie/v1/merchant/getkey.js"></script> <script type="text/javascript"> // This function checks whether getkey.js is loaded. function is_pie_key_download_error() { if (( typeof(PIE) == 'undefined') || (typeof(PIE.K) == 'undefined') || (typeof(PIE.L) == 'undefined') || (typeof(PIE.E) == 'undefined') || (typeof(PIE.key_id) == 'undefined') || (typeof(PIE.phase) == 'undefined')) { return true; } return false; } // This function checks whether encryption.js is loaded. function is_pie_encryption_download_error() { if ((typeof ValidatePANChecksum != 'function') || (typeof ProtectPANandCVV != 'function')) { return true; } return false; } function doEncryption() {


https://safetechpageencryption-dev.salem.paymentech.com/pie/v1/encryption.js

https://safetechpageencryption-dev.salem.paymentech.com/pie/v1/merchant/getkey.js


APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued) Test JavaScript Examples – getkey.js and encryption.js, (Continued) if(is_pie_encryption_download_error()) { alert("Failed to load encryption.js file"); return; } if(is_pie_key_download_error()) { alert("Failed to load getkey.js file"); return; } var ccno = document.getElementById("cardNo").value; var cvv = document.getElementById("cvv").value; var embed = document.getElementById("embed").checked; if(embed) { // Check MOD 10 digit, since PIE embedded encryption // requires that the MOD 10 checksum is valid. if(!ValidatePANChecksum(ccno)) { alert("PAN has invalid checksum."); return false; } } var result = ProtectPANandCVV(ccno, cvv, !embed); if(result != null) { document.getElementById("cryptCard").value = result[0]; document.getElementById("cryptCvv").value = result[1]; if (result.length > 2) document.getElementById("integrityCheckVal").value = result[2]; } else { alert("Error: ProtectPANandCVV call returned null. You may have entered an invalid card number."); } document.getElementById("keyId").value = PIE.key_id; document.getElementById("phase").value = PIE.phase; return false; }



APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued) Test JavaScript Examples – getkey.js and encryption.js, (Continued) </script>  </head> <body> <form id="pieForm" method="post" action="" onsubmit="return false;"> <h1>Safetech Page Encryption Example</h1> <div class="demo-card-information"> <div class="merchant-details"> <h2>Card Information</h2> <div class="row"> <label id="cardLabel" for="cardNo">Card Number</label> <input id="cardNo" name="cardNo" type="text" /> </div> <div class="row"> <label id="cvvLabel" for="cvv">CVV</label> <input type="text" id="cvv" name="cvv" /> </div> <div class="row"> <label id="embedLabel" for="embed">Embed key</label> <input type="checkbox" id="embed" name="embed" value="Y" /> </div> <div class="row"> <div id="leftBut" class="butFloat"> <button class="blueButton" id="encrypt" onclick="return doEncryption()"><span>Encrypt Card</span></button> </div> <div id="rightBut" class="butFloat"> <button class="greyButton" id="encrypt" onclick="window.location.href=window.location.href"><span>Reload Page</span></button> </div> </div> </div> </div>



APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued) Test JavaScript Examples – getkey.js and encryption.js, (Continued) <div class="demo-card-results"> <div class="merchant-details"> <h2>Results</h2> <div class="row"> <label id="cryptCardLabel" for="cryptCard">Encrypted Card</label> <input id="cryptCard" name="cryptCard" type="text" readonly /> </div> <div class="row"> <label id="cryptCvvLabel" for="cryptCvv">Encrypted CVV</label> <input id="cryptCvv" name="cryptCvv" type="text" readonly /> </div> <div class="row"> <label id="phaseLabel" for="phase">Phase</label> <input id="phase" name="phase" type="text" readonly /> </div> <div class="row"> <label id="keyIdLabel" for="keyId">Key ID</label> <input id="keyId" name="keyId" type="text" readonly /> </div> <div class="row"> <label id="integrityCheckValLabel" for="integrityCheckVal">Integrity Check</label> <input id="integrityCheckVal" name="integrityCheckVal" type="text" readonly /> </div> </div> </div> </form> </body> </html>



Test Output to Merchant Web Server

The following is output from the encryption.js for both eFPE and FPE.

// Copy other values directly. document.encryptedform.name.value = document.clearform.name.value; document.encryptedform.addr.value = document.clearform.addr.value; document.encryptedform.payment.value = document.clearform.payment.value; document.encryptedform.expiryMonth.value = document.clearform.expiryMonth.value; document.encryptedform.expiryYear.value = document.clearform.expiryYear.value; // OK to submit form to server. return true; } else { // Unable to encrypt; print message and don't submit form. alert("Failed to encrypt data. Please check the input values."); return false; } } // end of do_pie_embedded_encrypt

getkey.js Return Fields

The following chart lists the return fields of the getkey.js and how they map to the transaction fields or encryption.js.


getkey.js Return Field

Transaction Field Comments

One-time Key Used in encryption.js PIE.key_id Key ID

PIE.phase Phase ID

PIE.L and PIE.E The combination of these is the Format ID

Format ID

Integrity Check Returned from encryption.js



How It Works –Tokenization Only

Tokens can be created for clear account numbers and can be used for subsequent transactions. Tokenization can be utilized without page encryption.


Account numbers can be tokenized as a standalone transaction or as part of other action codes as noted in the Supported Action Codes in this appendix.

The token format is set as a transaction division default.

Merchant Services supports token servers in two geographic locations. If a token only request (Action Code = TN) is returned with Response Reason Code 281 (Token Unavailable) the request should be sent to the alternate server.

When Encryption Flag = 203 and a token cannot be returned, the transaction is processed. The Token ID Reply Format Indicator is not returned. If the transaction is approved (Response Reason Code = 100 (Approved)), a new request using Action Code = TN should be sent to tokenize the account number.




Sample Tokens for Tokenization

Example of 16 byte account number using first 6 / last 4 – all numeric (Division Default = 64NI/NI64).

Clear Account Number to Token 5454545454545454 to 5454543421855454

Note: This format ignores MOD 10.

Example of 16 byte account number using first 6 / last 4 – with alpha (Division Default = 64AI/AI64).

Clear Account Number to Token 5454545454545454 to 545454DJKEUA5454


Example of 16 byte account number using first 6 / last 4 – MOD10 and Checksum preserved (Division Default = 64NP/NP64).


Note: This format preserves MOD 10 and Checksum.

Example of 16 byte account number using first 6 / last 4 – Checksum changed (Division Default = 64NC/NC64).





APPENDIX O: SAFETECH PAGE ENCRYPTION AND TOKENIZATION, (Continued) Safetech Tokenization Format Examples

PAN Digits to Preserve

Alpha Token Indicator

MOD 10 Checksum

SST2* Format

Example Token Example MOD 10 Deprecated SST* Format

First 6 and Last 4 None Ignore MOD 10 NI64 5454541002111234 Fail/Ignore 64NI First 6 None Ignore MOD 10 NI60 5454541002112001 Fail/Ignore 60NI Last 4 None Ignore MOD 10 NI04 1806551002111234 Fail/Ignore 04NI None None Ignore MOD 10 NI00 1806551002112001 Fail/Ignore 00NI First 6 and Last 4 None Preserve MOD 10 NP64 5454541002801234 40 64NP First 6 None Preserve MOD 10 NP60 5454541002482001 40 60NP Last 4 None Preserve MOD 10 NP04 1806551001011234 40 04NP None None Preserve MOD 10 NP00 1806551004312001 40 00NP First 6 and Last 4 None Change MOD 10 NC64 5454541002981234 50 64NC First 6 None Change MOD 10 NC60 5454541019982001 50 60NC Last 4 None Change MOD 10 NC04 1806551002671234 50 04NC None None Change MOD 10 NC00 1806551008782001 50 00NC First 6 and Last 4 Alpha

Token Ignore MOD 10 AI64 5454541wrtp11234 Fail/Ignore 64AI

First 6 Alpha Token

Ignore MOD 10 AI60 5454541wrtp12001 Fail/Ignore 60AI

Last 4 Alpha Token


None Alpha Token


*SST = Secure Stateless Tokenization

Note: Formats have been upgraded to the new SST2 format.



Supported Action Codes

Safetech Page Encryption CNP and Tokenization supports the following Action Codes.

Note: If Encryption Flag = 201, 202, 203, or 204 and the action code is not in the table above, the transaction rejects with Response Reason Code 283 (Invalid Action for Encryption Type).


Online 120 Byte 96 Byte Description AR AR E Auth Reversal AU AU A Authorize AV n/a n/a Re-Activation Reversal BI BI Q Current Balance Inquiry CV n/a n/a Redemption Completion Reversal n/a DC B Conditional Deposit n/a DP D Deposit DR DR n/a Refund Auth Reversal DV n/a n/a De-activation Reversal FA FA n/a Fraud Analysis IR n/a n/a Issuance Activation Reversal PA PA n/a Purchase Auth PR PR n/a Purchase Auth Reversal PV n/a n/a Redemption Reversal RA RA n/a Refund Auth RC RC n/a Redemption Completion RF RF R Refund RP n/a n/a Redemption RV n/a n/a Refund Reversal SA SA L Add Value SD n/a n/a De-activation SI SI K Issuance Activation SV n/a n/a Re-activation TN TN Z Token Only Request n/a UP U Account Updater VF VF F Account Verification VR n/a n/a Add Value Reversal



Supported Methods of Payment (MOPs)

Safetech Page Encryption CNP and Tokenization supports the following Methods of Payment.

* Indicates a Method of Payment that potentially does not MOD 10 check. Notes: For Safetech Page Encryption eFPE support, only MOD 10 check digit account numbers are supported. If Encryption Flag = 201, 202, 203, or 204 and the method of payment is not in the table above, the transaction rejects with Response Reason Code 284 (Invalid MOP for Encryption Type).

MOP Description Page Encryption

Tokenization

AP ACCEL PINless Debit Yes * Yes AX American Express Yes Yes CR ChaseNet - Signature

Debit/Prepaid Yes Yes

CZ ChaseNet - Credit Yes Yes DD Discover Diners Yes Yes DI Discover Yes Yes DP Generic PINless Debit Yes * Yes IM International Maestro Yes Yes JC JCB Yes Yes MC MasterCard Yes Yes MR MasterCard Canadian

Domestic Restricted Debit Yes Yes

NP NYCE PINless Debit Yes * Yes PP Pulse PINless Debit Yes * Yes SP Star PINless Debit Yes * Yes SV Gift Card Yes Yes VI Visa Yes Yes VR Visa Canadian Domestic

Restricted Debit Yes Yes




Page Encryption CNP with FPE Transaction Types and Requirements

Process a transaction using FPE and return a token. Online Request:


a. MOP = AP, AX, CR, CZ, DD, DI, DP, IM, JC, MC, MR, NP, PP, SP, SV, VI, VR

b. Account Number = encrypted account number c. Encryption Flag = 201 d. Action Code = AR, AU, AV, BI, CV, DR, DV, FA, IR, PA, PR,

PV, RA, RC, RF, RP, RV, SA, SD, SI, SV, TN, VF, VR


a. Safetech Page Encryption (EI) i. Subscriber ID ii. Format ID iii. Integrity Check

iv. Key ID v. Phase ID

b. Fraud (FR) Response:



a. Token ID (TI)




Page Encryption CNP with FPE Transaction Types and Requirements, (Continued)

FPE and return a token, (Continued)

Batch Request:


a. Action Code = AR, AU, BI, DC, DP, DR, FA, PA, PR, RA, RC, RF, SA, SI, TN, UP, VF

b. Account Number = encrypted account number c. MOP = AP, AX, CR, CZ, DD, DI, DP, IM, JC, MC, MR, NP,

PP, SP, SV, VI, VR

d. Encryption Flag = 201 2. Product Records

a. Safetech Page Encryption (PEI001) i. Subscriber ID ii. Format ID iii. Integrity Check

iv. Key ID v. Phase ID

b. Fraud (PFR001) Response:


2. Product Record

a. Token ID (PTI001)




Page Encryption CNP with eFPE Transaction Types and Requirements

Process a transaction using eFPE and return a token. Online Request:


a. MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, SV, VI, VR

b. Account Number = encrypted account number (for account numbers that pass MOD 10)

c. Encryption Flag = 202

d. Action Code = AR, AU, AV, BI, CV, DV, FA, IR, PV, RC, RF, RP, RV, SA, SD, SI, SV, TN, VF, VR


a. Safetech Page Encryption (EI) i. Subscriber ID

ii. Format ID

iii. Integrity Check

b. Fraud (FR)

Response:



a. Token ID (TI)




Page Encryption CNP with eFPE Transaction Types and Requirements, (Continued)

eFPE and return a token, (Continued)

Batch Request:


a. Action Code = AR, AU, BI, DC, DP, FA, RC, RF, SA, SI, TN, UP, VF

b. Account Number = encrypted account number (for account numbers that pass MOD 10)

c. MOP = AX, CR, CZ, DD, DI, IM, JC, MC, MR, SV, VI, VR

d. Encryption Flag = 202

2. Product Records

a. Safetech Page Encryption (PEI001)

i. Subscriber ID

ii. Format ID

iii. Integrity Check

b. Fraud (PFR001)

Response:


2. Product Record





Tokenization Transaction Types and Requirements

Process a transaction using a clear account number or a token and return a token. Online Request:


a. MOP = AP, AX, CR, CZ, DD, DI, DP, IM, JC, MC, MR, NP, PP, SP, SV, VI

b. Account Number = clear or previously tokenized account number

c. Encryption Flag = 203 or 204

d. Action Code = AR, AU, AV, BI, CV, DR, DV, FA, IR, PA, PR, PV, RA, RC, RF, RP, RV, SA, SD, SI, SV, TN, VF, VR

Response:



a. Token ID (TI)

Batch Request:


a. Action Code = AR, AU, BI, DC, DP, DR, FA, PA, PR, RA, RC, RF, SA, SI, TN, UP, VF

b. Account Number = clear or previously tokenized account number

c. MOP = AP, AX, CR, CZ, DD, DI, IM, JC, MC, MR, NP, SP, SV, VI

d. Encryption Flag = 203 or 204

Response:


2. Product Record






Appendix E: Card Security Verification

Appendix F: Authorization Reversals

Appendix L: Debit Processing


American Express / All currencies

Discover and Discover Diners / U.S. Dollars and Canadian Dollars

Gift Card / U.S. Dollars

International Maestro / All currencies

ChaseNet (for U.S. merchants) / U.S. Dollars

JCB (for U.S. merchants) / U.S. Dollars

MasterCard / All currencies


PINless Debit / U.S. Dollars

Visa / All currencies




To Get Started

Contact your Merchant Services Representative


APPENDIX P: GIFT CARD Introduction Givex’s Gift Card program provides an electronic stored value payment

instrument through the use of plastic cards encoded with a magnetic stripe or an electronic certificate cross-referenced to a Gift Card number. The card or electronic certificate is used by the merchant to issue spending credit to their customers, for popular uses including gift certificates, merchandise return cards, and prepaid cards.

How It Works The merchant’s customer is given a magnetic stripe card or an electronic

certificate in exchange for money received, merchandise returned, or other considerations. The card/certificate represents a dollar value that the merchant’s customer can either use or give to another individual. The actual record of the balance on the account is maintained on Givex’s Gift Card database.

The electronic certificate may reflect the actual Gift Card number, or may be an alias for a Gift Card number stored on the merchant’s system.

The plastic card is designed to be swiped through a POS terminal or system. Since Gift Card is a multi-channel stored value program, the card number may also be key-entered into a merchant’s payment page on their Web site, or it may be entered by a Customer Service Representative at a merchant’s call center.

In either scenario, the Gift Card number is transmitted with the appropriate action code. The transaction returns a response to the merchant and updates the Gift Card database.

Depending on the merchant setup, a Gift Card may have a fixed balance, have allowable minimum and maximum amounts, allow value to be added, and/or contain an added security feature known as CVD2 (Card Verification Data), which is similar to credit card security value.

Please contact your Givex Representative for all editing rules.



APPENDIX P: GIFT CARD, (Continued)

Merchant Initiated Authorization Reversals

The following criteria is used to find a matching authorization for the authorization reversal:

a. Account number b. Division c. Order Number d. Amount e. Complimentary Action Code





Balance Inquiry obtains the current balance on an account. Online Request:

1. Online Processing Detail Record a. Action Code = BI b. Amount = all zeros

2. Format Indicator a. Retail (RE) or Retail 3 (R3) (Optional)

Response:

1. Online Processing Return Format Record 2. Reply Format Indicator

a. Gift Card (FC) Batch Request:


a. Action Code = BI

b. Amount = all zeros

2. Product Record

a. Gift Card (PSV001)

Response:


2. Product Record

a. Gift Card (PSV001)






1. Online Processing Detail Record a. Action Code = AU

2. Format Indicators a. Fraud (FR) (Optional) b. Retail (RE) or Retail (R3) (Optional)

Response:



a. Gift Card (FC)

i. Original Reference Number

Batch Request:


a. Action Code = AU

2. Product Records


b. Gift Card (PSV001) (Optional)

Response:


2. Product Record

a. Gift Card (PSV001) (Optional)





Authorization Reversal reverses a prior authorization transaction and releases the open to buy.

Online Request:


a. Action Code = AR


a. Retail (RE) or Retail 3 (R3) (Optional)

b. Reversal – Gift Card (RV) (Optional)

i. System Assigned Reference Number

Response:


Batch Request:


a. Action Code = AR

2. Product Record


Response:


2. Product Record






Redemption Completion redeems the amount processed in a prior authorization. This is similar to Action Code = DP (Deposit). Online Request:


a. Action Code = RC

b. Merchant Order Number

Note: This field must be the same value as sent on the authorization, otherwise, this transaction is processed as a Redemption.

Response:



a. Gift Card (FC)






Deposit redeems the amount processed in a prior authorization. This is similar to Action Code = RC (Redemption Completion). Batch Request:


a. Action Code = DP

b. Merchant Order Number

Note: This field must be the same value as sent on the authorization, otherwise, this transaction is processed as a Redemption.

2. Product Record


Response:


2. Product Record






Redemption Completion Reversal reverses a prior redemption completion transaction. Online Request:


a. Action Code = CV

2. Format Indicator

a. Reversal – Gift Card (RV) (Optional)


Response:






Refund adds amount to the balance of an active gift card. Can be thought of an “Add Value” to the Gift Card. Online Request:


a. Action Code = RF

Response:



a. Gift Card (FC)


Batch Request:


a. Action Code = RF

2. Product Record


Response:


2. Product Record






Refund Reversal reverses a prior refund transaction. Online Request:


a. Action Code = RV

2. Format Indicator



Response:






Redemption checks the available balance on the gift card and, if the balance is high enough, redeems the amount from the account. Online Request:


a. Action Code = RP

b. Amount cannot be all zeros

Response:



a. Gift Card (FC)






Redemption Reversal reverses a prior redemption transaction. Online Request:


a. Action Code = PV

2. Format Indicator



Response:






Issuance Activation issues and activates a gift card. Online Request:


a. Action Code = SI


Response:



a. Gift Card (FC)


Batch Request:


a. Action Code = SI


2. Product Record


Response:


2. Product Record






Issuance Activation Reversal reverses a prior issuance activation transaction. Online Request:


a. Action Code = IR

2. Format Indicator



Response:






Add Value adds amount to an active gift card. Online Request:


a. Action Code = SA

Response:



a. Gift Card (FC)


Batch Request:


a. Action Code = SA

2. Product Record


Response:


2. Product Record






Add Value Reversal reverses a prior add value transaction. Online Request:


a. Action Code = VR

2. Format Indicator


Response:






Deactivation reverses a prior add value transaction. Online Request:


a. Action Code = SD

b. Amount = all zeros

Response:



a. Gift Card (FC)

i. Previous Balance

ii. Original Reference Number





Deactivation Reversal reverses a prior deactivation transaction. Online Request:


a. Action Code = DV

b. Amount = Previous Balance in Reply Format Indicator Gift Card (FC) when Action Code = SD

2. Format Indicator



Response:






Reactivation reactivates a gift card account that was previously deactivated. Online Request:


a. Action Code = SV

b. Amount = Cannot be all zeros

Response:



a. Gift Card (FC)






Reactivation Reversal reverses a prior reactivation transaction. Online Request:


a. Action Code = AV

b. Amount = All zeros

2. Format Indicator



Response:






Block Activation activates up to 100 gift cards at one time. Online Request:


a. Action Code = BA

b. Account Number = First account number in the block

2. Format Indicator

a. Gift Card (FC)

i. Number of Cards for Block Activation

Response:



a. Gift Card (FC)






Block Activation Reversal reverses a prior block activation transaction. Online Request:


a. Action Code = BV

b. Amount = Amount of the original Block Activation transaction

c. Account Number = First account number in the block


a. Gift Card (FC)

i. Number of Cards for Block Activation

b. Reversal – Gift Card (RV) (Optional)


Response:








Gift Card / U.S. Dollar



To Get Started



APPENDIX Q: MONEYPAK Introduction MoneyPak is an alternative payment method that allows customers to turn

physical cash into electronic cash via the purchase of a MoneyPak card. Unlike other methods of payment there is no need for account approval, banking relationships, personal information sharing or credit card checks. This card can then be used at Merchant Services for Card Not Present (CNP) transactions.

How It Works MoneyPak is fully integrated as a method of payment into the Merchant

Services infrastructure. Merchants have a consolidated payments solution including single file transmission (all methods of payment), reporting, funding, and exceptions management.

MoneyPak is only able to process one authorization for a specific account number at a time. If the first MoneyPak transaction is not fully processed by the Issuer, subsequent transactions may be declined with Response Reason Code 303 (Processor Decline).

Transaction Matching Criteria

The following chart identifies the matching and validation processes. Both matching and validation must be successful for a transaction to deposit or refund.

Batch Matching for Purchase Authorization (PA) to Deposit (DP) and Refund Authorization (RA) to Refund (RF) uses Division Number, Amount, Confirmation ID, and Account Number. Processing Mode



Batch Match Found Merchant Services considers the transaction settled. Transaction is deposited.



APPENDIX Q: MONEYPAK, (Continued)


Balance Inquiry obtains the current balance on an account. Online Request:

1. Online Processing Detail Record a. Action Code = BI b. Account Number = Account Number if length is less than 20

bytes. c. Transaction Type = 1, 7, or 8

2. Format Indicator a. MoneyPak (MP) (Optional)

i. MoneyPak Account Number = Account Number if length is equal to 20 bytes.

Response:


a. Balance Inquiry (BQ)

b. MoneyPak (MP) (Optional)

i. MoneyPak Account Number





Balance Inquiry, (continued) Batch Request:


a. Action Code = BI

b. Account Number = Account Number if length is less than 20 bytes.


2. Extension Record



Response:

1. "S" Record Output 2. Extension Record

a. MoneyPak (EMP001) (Optional) i. MoneyPak Account Number

3. Product Record a. Balance Inquiry (PBQ001)





Purchase Authorization verifies the customer’s balance and, if the funds are available, debits the customer’s account. Online Request:

1. Online Processing Detail Record a. Action Code = PA b. Account Number = Account Number if length is less than 20

bytes c. Transaction Type = 1, 7, or 8

2. Format Indicators a. MoneyPak (MP) (Optional)


b. Partial Authorization (PB) (Optional) Response:


a. MoneyPak (MP) (Optional) i. Original Transaction ID ii. Confirmation ID iii. MoneyPak Account Number (Optional)






Purchase Authorization, (continued) Batch Request:


a. Action Code = PA



2. Extension Record



3. Product Record


Response:


a. MoneyPak (EMP001) (Optional) i. Original Transaction ID ii. Confirmation ID iii. MoneyPak Account Number (Optional)

3. Product Record a. Partial Authorization (PPB001) (Optional)






Refund Authorization returns funds to the customer for a previously approved purchase authorization. Online Request:

1. Online Processing Detail Record a. Action Code = RA b. Account Number = Account Number if length is less than 20

bytes. c. Transaction Type = 1, 7, or 8 d. Amount

2. Format Indicator a. MoneyPak (MP)

i. Original Transaction ID = the Original Transaction ID returned at authorization

ii. Confirmation ID = the Confirmation ID returned at authorization.

iii. MoneyPak Account Number = Account Number if length is equal to 20 bytes. (Optional)

Response:


a. MoneyPak (MP) (Optional) i. Original Transaction ID = new if transaction is

approved ii. Confirmation ID = new if transaction is approved iii. MoneyPak Account Number (Optional)




Refund Authorization, (Continued) Batch Request:


a. Action Code = RA



d. Amount

2. Extension Record

a. MoneyPak (EMP001)




Response:


a. MoneyPak (EMP001) (Optional) i. Original Transaction ID = new if the transaction is

approved ii. Confirmation ID = new if the transaction is approved iii. MoneyPak Account Number (Optional)





Deposit completes the Purchase Authorization. Batch Request:


a. Action Code = DP



d. Amount = Original, authorized amount

2. Extension Record





Response:







Refund completes the Refund Authorization. Batch Request:


a. Action Code = RF


c. Transaction Type = 1, 7 or 8

d. Amount = Original, approved, authorized refund amount.

2. Extension Record


i. Original Transaction ID = the Original Transaction ID returned at refund authorization

ii. Confirmation ID = the Confirmation ID returned at refund authorization.


Response:







MoneyPak / U.S. Dollar



To Get Started



APPENDIX R: HEALTH BENEFIT CARDS Introduction A customer uses a Health Benefit Card (HBC) to make purchases that

qualify under a healthcare plan. Types of healthcare plans include Flexible Spending Accounts (FSA), Healthcare Reimbursement Accounts (HRA) and Health Savings Accounts (HSA). These cards are loaded based on the various healthcare plan requirements and depleted as the cards are used.

Health benefits are supported by Merchant Services for ChaseNet, MasterCard, Visa and PIN-Based Debit.

The Internal Revenue Service (IRS) mandates that only healthcare specific purchases can be made using Health Benefit Cards.

Merchants are encouraged to retrieve the HBC BIN file to determine eligibility of an account.

The Merchant Category Code (MCC) must be healthcare specific in order for the HBC to be accepted without risk of a healthcare specific decline or a reject.

If the MCC is not healthcare specific, the merchant must show that an HBC can be used for some or all of the purchase. In this case the merchant must:

• Install an Inventory Information Approval System (IIAS). The IIAS separates the Qualified Healthcare-eligible Purchases (QHP) from the non-eligible purchases in the transaction, a process called "auto-substantiation".

• Register with the Special Interest Group for IIAS Standards (SIGIS). Failure to follow these steps results in transactions being declined or rejected.

How It Works The IIAS separates the healthcare specific amounts into specific

categories so that they can be identified as qualified healthcare purchases.

• QHP amount – Total of all qualified healthcare purchases. These amounts include: RX amount – the total of all prescription purchases. Vision amount – the total of all Vision purchases. Clinic/Other amount – the total of all additional qualified

purchases at a clinic or healthcare facility or other qualified medical purchases.

Dental amount – the total of all dental purchases.

These amounts are included as part of the Amount in the input record but are also explicitly listed in either the online Healthcare IIAS Format Indicator (II) or the batch Product Record Healthcare IIAS (PII001).

The QHP amount is required at authorization for an HBC when the merchant is using a non-healthcare specific MCC or the transaction rejects with Response Reason Code 265 (Missing QHP Amount). The other amounts are optional.



APPENDIX R: HEALTH BENEFIT CARDS, (Continued)


This information is sent on the authorization request. Merchants that do not authorize at Merchant Services must provide the appropriate Issuer program code at settlement to indicate that this is a qualified (auto-substantiation) healthcare transaction.

To ensure approval of all or part of the qualified healthcare transaction, merchants should be certified for partial authorizations.

Examples Example 1: Assume the amount on the HBC card is greater than the

amount of the healthcare purchases and that the transaction includes the following purchases:

• Greeting cards totaling $5.00 • Prescription totaling $15.00 • Crutches totaling $30.00

The transaction data would be: • Total transaction amount is $50.00 • QHP Amount is $45.00 (Prescription plus Crutches) • RX Amount is $15.00 (Prescription) • Clinic/Other amount is $30.00 (Crutches)

1. Assuming the merchant has been certified to process partial authorizations, a partial authorization of $45.00 would be returned for the HBC eligible purchase amount.

2. If the merchant is not certified to process partial authorizations the merchant would receive a decline for the full amount of $50.00.




Examples, (Continued)

Example 2: Assume the amount on the HBC card is less than the amount of the healthcare purchases and that the transaction includes the following purchases:

• Greeting cards totaling $5.00 • Prescription totaling $15.00 • Crutches totaling $30.00

The transaction data would be:

• Total transaction amount is $50.00 • QHP Amount is $45.00 • RX Amount is $15.00 • Clinic/Other amount is $30.00

1. Assuming the merchant has been certified to process partial authorizations and there is $10.00 available on the HBC card, a partial authorization of $10.00 would be returned for the HBC eligible purchase amount.

2. If the merchant is not certified to process partial authorizations the merchant would receive a decline for the full amount of $50.00.

Example 3: Assume that an HBC is used for a transaction with no healthcare eligible purchases and that the transaction includes the following purchase:

• Greeting cards totaling $5.00

The transaction data would be:

• Total transaction amount is $5.00

1. Regardless of the amount available on the card, the transaction rejects with Response Reason Code of 265 (Missing QHP Amount) because there is no qualified healthcare data.







a. Action Code = AU or PA


a. Healthcare IIAS (II)

b. Debit Information (DB) – PIN-Based Debit Only (Optional)

c. Partial Authorization (PB) (Optional)

d. Retail (RE) or Retail 3 (R3) (Optional)

Response:



a. Cash Back (CO) (Optional)

b. Debit (DB) – PIN-Base Debit Only (Optional)

c. Partial Authorization Reply (PB) (Optional) Batch Request:


a. Action Code = AU

2. Product Records

a. Healthcare IIAS (PII001)

b. Partial Authorization (PPB001) (Optional)

Response:


2. Product Record a. Partial Authorization (PPB001) (Optional)





Conditional Deposit verifies accountholder’s open-to-buy and if the funds are available, debits the accountholder’s account and funds the merchant. Batch Request:


a. Action Code = AU

2. Product Records

a. Healthcare IIAS (PII001)

b. Partial Authorization (PPB001) (Optional)

Response:


2. Product Record






Appendix G: Partial Authorization



ChaseNet, MasterCard, Visa, and PIN-Based Debit / U.S. Dollar





APPENDIX S: PAYPAL Introduction PayPal is an online alternative payment for online retailers. PayPal has

partnered with Merchant Services to combine all the functionality of Merchant Services’ robust payment services with the market opportunity of PayPal’s expanding customer base.

How It Works PayPal is fully integrated as a method of payment into the Merchant Services

infrastructure. Merchants have a consolidated payments solution including single file transmission (all methods of payment), reporting, funding and exceptions management.

There are multiple ways that a transaction can be processed. This appendix documents the most logical ways.

Field Specific Information

Account Number may contain dashes. Payment Status located on the batch Extension Record: PayPal 2 (EPY002) has the following values:

Values Description

A1 Cancelled A2 Cleared A3 Completed A4 Denied A5 Expired A6 Failed A7 Pending A8 Refunded A9 Returned B1 Reversed B2 Unclaimed B3 Uncleared B4 Complete B5 Held B6 In Progress B7 Partially Captured B8 Partially Refunded B9 Placed C1 Removed C2 Voided C3 Processed



APPENDIX S: PAYPAL, (Continued)

Payment Actions

The following Subtype Flags are used to identify the transaction.

Subtype Flag Description

Authorization (A) Confirms customer account is in good standing, funds may be reserved (Credit Card Methods of Payment).

Authorization and Create Billing Agreement (B)

Authorizes and creates billing agreement between the merchant and customer for future payments.

Create Billing Agreement (C) Sets up billing agreement for future payments. Do Auth is required.

Order and Create Billing Agreement (E)

One time order valid for 29 days and sets up billing agreement for future payments. Do Auth is required.

Order (O) One time order. Do Auth is required.





Set Express Payment allows a merchant to establish a session with PayPal for the purpose of allowing an accountholder to pay for a purchase using a PayPal account.

Online Request:

1. Online Processing Detail Record a. Action Code = ES b. Account Number = all 1’s c. Amount = total cost, including tax and excluding shipping

Note: Can be zero when Subtype Flag = C (Create Billing Agreement).

2. Format Indicators a. Email Address (AL) (Optional)

i. Address Subtype = B (Bill To/Buyer Email Address) b. Agreement Description (BD) (Optional) c. Ship To Address (HN and AS) (Optional) d. Page Setup (PS) (Optional)

i. Fields can be sent to override transaction division defaults.

e. Payment Action (PM) i. Subtype Flag = A (Authorization), or

B (Authorization and Create Billing Agreement), or C (Create Billing Agreement), or E (Order and Create Billing Agreement), or O (Order)

f. Token ID (TI) (Optional) i. Used to reset the clock for the timing of an

authorization or order. g. URL and Address Flag (US)

i. No Shipping Address Display Note: When No Shipping Address Display = N and no shipping address is sent by the merchant, the customer sees their PayPal shipping address when logging in, but they cannot change it.





Set Express Payment, (continued)

Online Response:


a. Token ID (TI) i. Used by merchant to re-direct accountholder from

merchant website to PayPal website so that the accountholder can use PayPal to pay for a purchase.

ii. Expires after issuance. Default expiration time is 3 hours after issuance.

b. Response Message (RM) (Optional)





Get Express Payment returns accountholder information stored at PayPal.

Online Request:


a. Action Code = EG

b. Account Number = all 1’s

c. Amount = Any amount greater than zero.



a. Token ID (TI)

i. Token ID = Time-stamped token returned from Set Express Payment

b. Payment Action (PM) i. Subtype Flag = A (Authorization), or

B (Authorization and Create Billing Agreement), or C (Create Billing Agreement), or E (Order and Create Billing Agreement), or O (Order)





Get Express Payment (continued)

Response:



a. Bill To Address (AB)

i. Only returned when URL and Address Flag Format Indicator (US) field Request to Confirm Addresses = A or B on the Set Express Payment transaction.

ii. This function must be enabled on PayPal’s system.

b. Email Address (AL)

c. Ship To Address (AS)

i. Only returned when URL and Address Flag Format Indicator (US) field Request to Confirm Addresses = A or Y.

d. Personal Information 2 (P2)

i. Payer ID

e. Token ID (TI)

f. Response Message (RM) (Optional)





Do Express Payment completes the accountholder’s involvement with the transaction.

Online Request:


a. Action Code = ED

b. Account Number = all 1’s

c. Amount = total cost, including tax and shipping



a. Token ID (TI)

i. Token ID = time-stamped token returned from Get Express Payment

b. Personal Information 2 (P2)

c. Ship To Address (HN and AS) (Optional) d. Payment Action (PM)

i. Subtype Flag = A (Authorization), or B (Authorization and Create Billing Agreement), or C (Create Billing Agreement), or E (Order and Create Billing Agreement), or O (Order)

Note: It is highly recommended to send Ship To address information to aid in chargeback research.





Do Express Payment, (continued)

Online Response:


a. Account Number - This is new if the transaction is approved, or this value is echoed from the input record.

i. New Authorization ID when Payment Action Format Indicator (PM) Subtype Flag = A or B

ii. Order ID when Payment Action Format Indicator (PM) Subtype Flag = E or O

iii. Billing Agreement ID when Payment Action Format Indicator (PM) Subtype Flag = C


a. Token ID (TI)

b. Transaction ID (TX) (Optional)

i. Billing Agreement ID when Payment Action Format Indicator (PM) Subtype Flag = B or E

c. Response Message (RM) (Optional)





Do Auth obtains an authorization for a prior order.

Online Request:


a. Action Code = AU

Authorize a prior order d. Account Number = Populate with Account Number returned

from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = E or O

c. Amount = total cost, including tax and shipping.


a. Payment Action (PM)

i. Subtype Flag = O (Order). This authorizes a prior order.


Note: Payer ID should be sent when Safetech fraud scoring is requested.

Response:


a. Account Number

i. This is new if the transaction is approved, otherwise this value is echoed from the online processing detail record.

ii. This value is used as the account number on the Do Capture transaction.


a. Transaction ID (TX)

i. Transaction ID = Inbound Account Number value.


Note: Approved orders are valid for 29 days. Approved authorizations are valid for 3 days. If a Do Capture transaction (batch only) is not sent within 3 days, a Do Auth on the original Order transaction must be submitted to obtain a new authorization.





Do Auth obtains an authorization for a Billing Agreement.

Online Request:


a. Action Code = AU

Authorize a Billing Agreement b. Account Number = Populate with Account Number returned

from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = C

Or

Account Number = Populate with Transaction ID returned from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = B or E




i. Subtype Flag = A (Authorize). This authorizes a Prior Billing Agreement.


Note: Payer ID should be sent when Safetech fraud scoring is requested.





Do Auth, (continued)

Online

Response:


a. Account Number

i. This is new if the transaction is approved, otherwise this value is echoed from the online processing detail record.












Batch Request:


a. Action Code = AU

Authorize a prior order b. Account Number = Populate with Account Number returned

from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = E or O


2. Extension Record

a. PayPal 1 (EPY001)

i. Subtype Flag = O (Order). This authorizes a prior order.

ii. Transaction ID = Should be blank

Response:


a. Account Number

i. This is new if the transaction is approved; otherwise this value is echoed from the input record.


2. Extension Record


i. Subtype Flag = Inbound Subtype Flag value.

3. Product Record

a. Response Message (PRM001) (Optional)







Batch Request:


a. Action Code = AU

Authorize a Billing Agreement b. Account Number = Populate with Account Number returned

from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = C

Or

Account Number = Populate with Transaction ID returned from a Do Express Payment transaction when Format Indicator Payment Action (PM) Subtype Flag = B or E


2. Extension Record

a. PayPal 1 (EPY001) i. Subtype Flag = A (Authorize). This authorizes a prior

billing agreement.

ii. Transaction ID = Should be blank






Batch Response:


a. Account Number

i. This is new if the transaction is approved; otherwise this value is echoed from the input record.


2. Extension Record



3. Product Record


Note: Approved orders are valid for 29 days. Approved authorizations are valid for 3 days. If a Do Capture transaction (batch only) is not sent within 3 days, a Do Auth on the original Billing Agreement transaction must be submitted to obtain a new authorization.





Do Void cancels a transaction ID (authorization, order, or re-authorization), billing agreement, or order that is not going to be used.

Online Request:


a. Action Code = AR

b. Account Number = Populate with Account Number returned when:

i. Do Express Payment transaction has Format Indicator Payment Action (PM) Subtype Flag =

A (Authorization) or

B (Authorization and Create Billing Agreement)

O (Order)

ii. Do Auth transaction is approved

iii. If voiding a transaction that has been re-authorized, use the Account Number from the original authorization (not the re-authorization Account Number).

c. Amount = Any amount greater than zero (field is ignored).



b. Various Text (VT) (Optional)

Response:










Do Void, (continued)

Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = AR b. Account Number = Populate with the Account Number

returned when: i. Do Express Payment transaction has Format

Indicator Payment Action (PM) Subtype Flag = A (Authorization) or B (Authorization and Create Billing Agreement) O (Order)

ii. Do Auth transaction is approved iii. If voiding a transaction that has been re-authorized,

use the Account Number from the original authorization (not the re-authorization Account Number).

c. Amount = Any amount greater than zero (field is ignored). 2. Extension Record

a. PayPal 1 (EPY001) 3. Product Record

a. Various Text (PVT001) (Optional) Response:


a. PayPal 1 (EPY001) i. Subtype Flag = Inbound Subtype Flag value ii. Transaction ID = Inbound Account Number value.

3. Product Record a. Response Message (PRM001) (Optional)





Do Capture obtains funds from the customer for the sale. Batch Request:

1. Merchant Descriptor Record ("M" Record) (Optional) a. Soft Merchant Name and/or Item Description

2. Detail Record ("S" Record Input) a. Action Code = RG b. Account Number = Populate with Account Number returned

when: i. Online transaction Do Express Payment had Format

Indicator Payment Action (PM) Subtype Flag = A (Authorization) or B (Authorization and Create Billing Agreement).

ii. Online transaction Do Auth or Do Re-Auth was approved.

iii. Batch transaction Do Auth or Do Re-Auth was approved.

c. Amount = total cost, including tax and shipping. d. Response Reason Code = Should be blank. e. Response Date = Should be blank. f. Authorization Code = Should be blank.

3. Extension Record a. PayPal 1 (EPY001)

i. Subtype Flag = F (Full) or P (Partial). Note: It is recommended by PayPal to always send P (Partial).

4. Product Record (Optional) a. Soft Merchant Information 1 (PSM001) (Optional)

i. DBA Notes: If multiple soft merchant information fields are populated for the transaction, the precedence from highest to lowest is:

• DBA (Product Record PSM001) • Soft Merchant Name and/or Item Description ("M" Record) • Transaction Division Default

The Descriptor should not contain the following values: Dash (-), asterisk (*), period (.), or blank (" ")





Do Capture, (Continued)

Response:


a. Account Number

i. This is new if the transaction is approved, otherwise this value is echoed from the input record.



i. Transaction ID = New if the transaction is approved, otherwise blank.

b. PayPal 2 (EPY002)

i. Payment Status

ii. Receipt ID (Returned at PayPal’s discretion).

3. Product Record


Notes: Do Capture must be done within 3 days of the original authorization. If a Do Capture transaction is not sent within 3 days, a Do Auth on the original Order or Billing Agreement transaction must be submitted to obtain a new authorization.

Partial captures can be done up to 10 times.





Do Refund refunds a full or partial payment.

Batch Request:


a. Action Code = RD

b. Account Number = Account Number returned from a successful sale (Do Capture or Recurring) transaction.

c. Response Reason Code = Should be blank.

d. Response Date = Should be blank.

e. Authorization Code = Should be blank.

2. Extension Record


i. Subtype Flag = F (Full) or P (Partial).

Note: PayPal recommends always sending "P" to avoid a PayPal decline when not refunding the full amount to the original Do Capture.

Response:


2. Extension Record



ii. Transaction ID = Transaction ID of the refund if the refund is approved.

3. Product Record






Recurring transactions are payments made in the same amount over a period of time at a regularly occurring rate.

Batch Request:


a. Action Code = RG

b. Account Number = All 1’s.

c. Amount = Amount customer is charged in one payment.

d. Response Reason Code = Should be blank.

e. Response Date = Should be blank.

f. Authorization Code = Should be blank.

2. Extension Record


i. Subtype Flag = R (Recurring Deposit).

ii. Contract ID/Billing Agreement ID

iii. Transaction ID = Should be blank on input.

Response:


a. Account Number

i. This is new if the transaction is approved or this value is echoed from the input record.

2. Extension Record



ii. Transaction ID = "S" Record Output Account Number

3. Product Record





Online Format Examples


1. Input for PayPal Set Express Payment for an authorization with optional Format Indicator PS (Page Setup): 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF PY11111111111111111 00001234560000000075758407 ES ALBJS

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 [email protected] ASD6038966000 JOHN D. *SMITH

18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 4 NORTHEASTERN BLVD USSALEM NH030 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 79 HNJOHN D. SMITH PSUSPageStyleIs30-charactersToHereFF 36 37 38 39 40 41 42 43 44 012345678901234567890123456789012345678901234567890123456789012345678901234567890 FFFF0000001A0F3D000PMAUS021MERCHANTORDERPAGE.COM027MERCHANTORDERCANCELPAGE.COMYN ↵

1. Return for PayPal Set Express Payment for an authorization: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100071222 11111111111111111 PY 000000007575TI22B

9 10 012345678901234567 B-123ZZ456RR789 ↵




Online Format Examples, (Continued)

2. Input for PayPal Get Express Payment for an authorization:

1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF PY11111111111111111 00001234560000000000008407 EG TI22B

9 10 11 012345678901234567890 B-123ZZ456RR789 PMA ↵

2. Return for PayPal Get Express Payment for an authorization: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100071222 11111111111111111 PY 000000000000ALBJS

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 [email protected] ASD6038966000 JOHN D. SMITH

18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 4 NORTHEASTERN BLVD USSALEM NH030

27 28 29 30 31 32 01234567890123456789012345678901234567890123456789012345678 79 P247SJ9XB93UNAA YYTI22BB-123ZZ456RR789 ↵





3. Input for PayPal Do Express Payment for an authorization: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF PY11111111111111111 00001234560000000085748407 ED TI22B

9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 B-123ZZ456RR789 PMAP247SJ9XB93UNAA ASD6038966000 JOHN D. *SMITH

18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 4 NORTHEASTERN BLVD USSALEM NH0307

27 28 29 30 31 32 012345678901234567890123456789012345678901234567890123 9 HNJOHN D. SMITH ↵

3. Return for PayPal Do Express Payment for an authorization: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100071222 1234-56ABC789DEF1 PY 000000008574TI22B

9 10 012345678901234567 B-123ZZ456RR789 ↵

4. Input for PayPal Do Void: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF PY1234-56ABC789DEF1 00001234560000000000008407 AR PMAVT

9 10 012345678901234 12TEXT MESSAGE ↵

4. Return for PayPal Do Void: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100071222 1234-56ABC789DEF1 PY 000000000000TX123

9 10 01234567890123456 4-56ABC789DEF1 ↵





5. Input for PayPal Set Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789XYZ PY1111111111111111111 00001234560000000075008407 ES ALBJB 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 [email protected] ASD6038968000 JOHN D. *BROWN 18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 4 NORTH END ST USSALEM NH030 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 79 HNJOHN BROWN PMOUS010RETRN URL010CANCEL URLYY ↵

5. Return for PayPal Set Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789XYZ 100071223 1111111111111111111 PY 000000007500TI194 9 10 012345678901234567 82901237501923847 ↵





6. Input for PayPal Get Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789XYZ PY1111111111111111111 00001234560000000000008407 EG PMOTI 9 10 11 012345678901234567890 19482901237501923847 ↵

6. Return for PayPal Get Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789XYZ 100071223 1111111111111111111 PY 000000007500ALBJB 9 10 11 12 13 14 15 16 17 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678 [email protected] ASD6038998100 JOHN D. BROWN 18 19 20 21 22 23 24 25 26 90123456789012345678901234567890123456789012345678901234567890123456789012345678901234567 4 NORTH END ST USSALEM 27 28 29 30 31 32 33 89012345678901234567890123456789012345678901234567890123456789012 NH03079 P2FYA122PZY387 YYTI19482901237501923847 ↵





7. Input for PayPal Do Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789XYZ PY1111111111111111111 00001234560000000075008407 ED ASD60 9 10 11 12 13 14 15 16 17 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678 38968000 JOHN D. *BROWN 4 NORTH END ST 18 19 20 21 22 23 24 25 26 90123456789012345678901234567890123456789012345678901234567890123456789012345678901234567 USSALEM NH03079 HNJOHN BROWN 27 28 29 30 31 32 89012345678901234567890123456789012345678901234567890123 P2FYA122PZY387 PMOTI19482901237501923847 ↵

7. Return for PayPal Do Express Payment for an order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789XYZ 100071223 O-3SL91821DT079602C PY 000000007500TI194 9 10 012345678901234567 82901237501923847 ↵

8. Input for PayPal Do Auth for a prior order: 1 2 3 4 5 6 7 8 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345 P74VABC123456789XYZ PYO-3SL91821DT079602C 00001234560000000075008407 AU PMO ↵

8. Return for PayPal Do Auth for a prior order: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789XYZ 100071223 693S89Z0987T079987D PY 000000007500TXO-3 9 10 01234567890123456 SL91821DT079602C ↵





9. Input for PayPal Set Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VEFG123456789DEF PY11111111111111111 00001234560000000050008407 ES ALBJC 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 [email protected] AS JOHN *CHASE 18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 7 HIDEAWAY RD USSALEM NH030 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 79 HNJOHN CHASE PMCUS021MERCHANTORDERPAGE.COM027MERC 36 37 38 01234567890123456789012345 HANTORDERCANCELPAGE.COMYN ↵

9. Return for PayPal Set Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VEFGC123456789DEF 100071224 11111111111111111 PY 000000005000 TI19 9 10 012345678901234567 48290123750192384 ↵





10. Input for PayPal Get Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VEFG123456789DEF PY11111111111111111 00001234560000000000008407 EG PMCTI 9 10 01234567890123456789 1948290123750192384 ↵

10. Return for PayPal Get Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VEFG123456789DEF 100071224 11111111111111111 PY 000000000000ALBJC 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 [email protected] AS JOHN CHASE 18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 7 HIDEAWAY RD USSALEM NH030 27 28 29 30 31 32 01234567890123456789012345678901234567890123456789012 79 P247SJ9XB93UNAA YYTI1948290123750192384 ↵

11. Input for PayPal Do Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VEFG123456789DEF PY11111111111111111 00001234560000000050008407 ED P247S 9 10 11 12 13 01234567890123456789012345678901234567890123456 J9XB93UNAA PMCTI1948290123750192384 ↵

11. Return for PayPal Do Express Payment for Create Billing: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VEFG123456789DEF 100071224 B-47SJ9XB93UNAABB PY 000000005000TI194 9 10 01234567890123456 8290123750192384 ↵




Batch Format Examples Sample Input File 1: 1 2 3 4 5 6 7 8 9 10 11 12 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 PID=987654 XYZCO SID=987654 XYZCO START 071226 3.0.0 DEPFILE [ 1] S0000123456ABC123456789DEF RGPY43-21ABC9876XYZ54 0000000085748401007 071222 [ 2] EPY001F [ 3] S0000123456XYZABC123456789 RDPYZ0-97531ASDF24681 000000004000840 7 [ 4] EPY001F [ 5] S0000123456123454321235567 ARPY1234-56ABC789DEF1 000000000000840 7 [ 6] EPY001A [ 7] PVT001MERCHANT CUSTOMIZED TEXT MESSAGE [ 8] S0000123456ASDFGHTREWQ1234 AUPY345321234567765RA 000000008500840 7 [ 9] EPY001A [10] S0000123456ABC123456789XYZ RGPY693S89Z0987T079987D 0000000075008401007 071223 [11] EPY001F [12] S0000123456EFG123456789DEF RGPY1111111111111111111 000000005000840 7 [13] EPY001RB-47SJ9XB93UNAABB [14] S0000123456ZXCVBNM12345678 RGPY1111111111111111111 000000000000840 7 [15] EPY001S [16] EPY002E [17] PVT001MERCHANT CUSTOMIZED TEXT MESSAGE [18] S0000123XXXASDFGH123451234 AUPY345321234567ABCDE 000000000100840 7 [19] EPY001A [20] B RECS=000000022 ORDS=000000008 $TOT=00000000033674 $SALE=00000000021074 $REFUND=00000000004000 [21] T RECS=000000023 ORDS=000000008 $TOT=00000000033674 $SALE=00000000021074 $REFUND=00000000004000 [22] PID=987654 XYZCO SID=987654 XYZCO END 071226 [23] EOFEOFEOF [24] 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 9 10 11 12

Please see the following page for Sample Input File 1 Line Item Description




Batch Format Examples, (Continued) Sample Input File 1 Line Item Description: Line 1: Header Record Line 2: Detail Record [PayPal Do Capture for a re-auth of a prior authorization – see online example #4] Line 3: Extension Record: PayPal 1 Line 4: Detail Record [PayPal Do Refund for a prior authorization] Line 5: Extension Record: PayPal 1 Line 6: Detail Record [PayPal Do Void for a prior authorization] Line 7: Extension Record: PayPal 1 Line 8: Format Indicator: Various Text Line 9: Detail Record [PayPal Do Re-Auth for a prior authorization] Line 10: Extension Record: PayPal 1 Line 11: Detail Record [PayPal Do Capture for a prior authorization – see online example #10] Line 12: Extension Record: PayPal 1 Line 13: Detail Record [PayPal Do Recurring for a prior Do Express Payment for Create Billing – see online example #13] Line 14: Extension Record: PayPal 1 Line 15: Detail Record [PayPal Mass Pay] Line 16: Extension Record: PayPal 1 Line 17: Extension Record: PayPal 2 Line 18: Format Indicator: Various Text




Batch Format Examples, (Continued) Sample Input File 1 Line Item Description (continued): Line 19: Detail Record [PayPal Do Re-Auth for a prior authorization with an invalid transaction division number] Line 20: Extension Record: PayPal 1 Line 21: Batch Totals Record Line 22: Totals Record Line 23: Trailer Record Line 24: EOFEOFEOF (Note: Only required for TCPIP protocol on inbound)




Batch Format Examples, (Continued) Sample Output File 1: 1 2 3 4 5 6 7 8 9 10 11 12 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 PID=987654 XYZCO SID=987654 XYZCO START 071226 3.0.0 DEPFILE [ 1] S0000123456ABC123456789DEF RGPYZ0-97531ASDF24681 0000000085748401007 071222 N [ 2] EPY001F 43-21ABC9876XYZ54 [ 3] EPY002 A3 123456789QWERTY00AB [ 4] S0000123456XYZABC123456789 RDPY12397531ASDF24681 0000000040008401007 071226 N [ 5] EPY001F 1234567890123456789 [ 6] S0000123456123454321235567 ARPY1234-56ABC789DEF1 0000000000008401007 071226 N [ 7] EPY001A 1234-56ABC789DEF1 [ 8] S0000123456ASDFGHTREWQ1234 AUPY43-21ABC9876XYZ54 0000000085008401007 071226 N [ 9] EPY001A 345321234567765RA [10] S0000123456ABC123456789XYZ RGPY7WA90785JL192681011 0000000075008401007 071223 N [11] EPY001F 693S89Z0987T079987D [12] S0000123456EFG123456789DEF RGPY98765432132165498 0000000050008401007 071226 N [13] EPY001RB-47SJ9XB93UNAABB 1111111111111111111 [14] S0000123XXXASDFGH123451234 AUPY345321234567ABCDE 0000000001008402317 071226 N [15] EPY001A 345321234567ABCDE [16] PRM001 INVALID DIVISION NUMBER [17] B RECS=000000022 ORDS=000000008 $TOT=00000000033674 $SALE=00000000021074 $REFUND=00000000004000 [18] T RECS=000000023 ORDS=000000008 $TOT=00000000033674 $SALE=00000000021074 $REFUND=00000000004000 [19] PID=987654 XYZCO SID=987654 XYZCO END 071226 [20] EOFEOFEOF [21] 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 9 10 11 12

Please see the following page for Sample Output File 1 Line Item Description




Batch Format Examples, (Continued) Sample Output File 1 Line Item Description: Line 1: Header Record Line 2: Detail Record [PayPal Do Capture for a re-auth of a prior authorization – see online example #4] Result Line 3: Extension Record: PayPal 1 Result Line 4: Extension Record: PayPal 2 Result Line 5: Detail Record [PayPal Do Refund for a prior authorization] Result Line 6: Extension Record: PayPal 1 Result Line 7: Detail Record [PayPal Do Void for a prior authorization] Result Line 8: Extension Record: PayPal 1 Result Line 9: Detail Record [PayPal Do Re-Auth for a prior authorization] Result Line 10: Extension Record: PayPal 1 Result Line 11: Detail Record [PayPal Do Capture for a prior authorization – see online example #10] Result Line 12: Extension Record: PayPal 1 Result Line 13: Detail Record [PayPal Do Reference for a prior Do Express Payment for Create Billing – see online example #13] Result Line 14: Extension Record: PayPal 1 Result Line 15: Detail Record [PayPal Do Re-Auth for a prior authorization with an invalid transaction division number] Result Line 16: Extension Record: PayPal 1 Result Line 17: Format Indicator: Response Message




Batch Format Examples, (Continued) Sample Output File 1 Line Item Description (continued): Line 18: Batch Totals Record Line 19: Totals Record Line 20: Trailer Record Line 21: EOFEOFEOF (Note: only required for TCPIP protocol on inbound, but created for all protocols on outbound unless otherwise requested.)





PayPal / U.S. Dollar



To Get Started



APPENDIX T: SOFT MERCHANT INFORMATION AND MERCHANT DESCRIPTOR

Introduction Soft merchant information is supported by Merchant Services for American Express, ChaseNet, Discover, Discover Diners, Electronic Check Processing (ECP), International Maestro, JCB, MasterCard, MasterCard Canadian Restricted Debit, PIN Debit, PINless Debit, Visa, and Visa Canadian Domestic Restricted Debit. Authorizations, deposits, and refunds support soft merchant information and Merchant Services recommends that the descriptor sent be the same for both the authorization and the deposit. There are two ways to send soft merchant information:

• Soft Merchant Information (excluding ECP) • Merchant Descriptor

Formatting Rules (All MOPs – Non-ECP)

If the Merchant Contact Information field, located on the batch Product Record: Soft Merchant Information 1 (SM001) or the Soft Merchant City/Customer Service Phone Number field, located on the Merchant Descriptor Format Indicator (MD) or the Batch Merchant Descriptor ("M" – Record) is populated, the value is sent to the appropriate association. If this field data begins with a numeric value, the field is considered a "phone number".

Valid phone number formats: • NNN-NNN-NNNN (U.S. and Canada)

• NNN-AAAAAAA (U.S. and Canada)

• NNN-NNNNNNN (U.S. and Canada)

Notes: ChaseNet (U.S. only), International Maestro, MasterCard, and Visa International transactions may include the above formats or any 13 byte format.

All other International Methods of Payment must follow one of the above formats.

Valid URL formats: • Must contain a "."

• Transaction Type = 5, 6, or 7 with MCC = 4816

• Transaction Type = 2 when MCC = 4812, 4814, 4899, 4900, 5960, 5968, 6300, 7298, 7997, 8675, or 8699 for all MOPs except ChaseNet and Visa. ChaseNet and Visa allow any MCC to be used.

Valid email address formats: • Must contain a "@"

• Transaction Type = 5, 6, or 7 with MCC = 4816

• Transaction Type = 2 when MCC = 4812, 4814, 4899, 4900, 5960, 5968, 6300, 7298, 7997, 8675, or 8699 for all MOPs except ChaseNet and Visa. ChaseNet and Visa allow any MCC to be used.



APPENDIX T: SOFT MERCHANT INFORMATION AND MERCHANT DESCRIPTOR, (Continued)

Soft Merchant Information

Certain merchants, such as Aggregator and Petroleum merchants, may have a need to include merchant identifying information with each transaction rather than using defaults that are stored in the Merchant Services Merchant Setup system. These merchants may take advantage of Merchant Services' Soft Merchant record specifications in order to submit such soft information as merchant name, street address, city, state and zip. The soft data that is submitted is passed to the card association along with the transaction and posted on the accountholder's statement, if applicable.

A merchant must be approved by the Merchant Services Risk/Credit department prior to becoming certified for submitting soft merchant information.

A flag at the transaction division level must be set to enable a merchant to send Soft Merchant Information format indicators and/or records. If the flag is not set, the transaction rejects with Response Reason Code 258 (Not Authorized to Send Record).

If both Soft Merchant Information and the Merchant Descriptor are sent on the same transaction, an order of precedence is followed. Please refer to the sections that follow for Method Of Payment (MOP) specifics when populating these fields and how they interact with other "soft" fields.

If an MCC is blocked for a merchant, and the MCC is sent with the transaction, the transaction rejects with Response Reason Code 249 (Invalid Merchant Category Code).

If any field is populated with invalid characters, the transaction rejects with Response Reason Code 225 (Invalid Field Data).

Valid characters are comprised of the following:

a – z A - Z 0 - 9 . < ( + & ! $ * )

; - ‘ % _ >

? : # @ = "

{ } space ^ “ '

| , "

( | ) Pipe character is blank or absent in Transaction History.



APPENDIX T: SOFT MERCHANT INFORMATION AND MERCHANT DESCRIPTOR,

(Continued) Merchant Descriptor

The Merchant Descriptor is used to define the merchant name/product description that appears on the accountholder’s statement. The description in the Soft Merchant Name and/or Item Description field should be what is most recognizable to the accountholder. It allows the merchant greater flexibility in describing the consumer’s purchase. In addition, the Merchant City/Customer Service Phone Number field allows the merchant to identify the business location or provide the accountholder with a customer service phone number or URL.

A merchant must be approved by Merchant Services Risk/Credit department to enable Soft Merchant Name and/or Item Description to be sent to the Card Brand.

The Merchant Descriptor Format Indicator (MD) and the Merchant Descriptor Record ("M" – Record) requires a transaction division level flag to be set.

It is subject to Issuer discretion whether this descriptor is displayed on the accountholder’s statement.

If both Soft Merchant Information and the Merchant Descriptor are sent on the same transaction, an order of precedence is followed. Please refer to the sections that follow for Method Of Payment (MOP) specifics when populating these fields and how they interact with other "soft" fields.

Merchant Services does not generate or segregate reports by Merchant Descriptor Record. If a merchant wishes to see reports segregated by product, the merchant must set up specific reporting Transaction Divisions and use them for processing.




Soft Merchant and Merchant Descriptor - Rules

Rules and Guidelines: (Non-ECP Transactions) A merchant must be approved by Merchant Services Risk/Credit department to enable Soft Merchant Name and/or Item Description to be sent to the Card Brand.

If the Soft Merchant Name and/or Item Description field is sent as blank, the transaction division default value is used.

If the Soft Merchant City/Customer Service Phone Number field is sent as blank, the transaction division default is used. In batch processing, the merchant descriptor records must be placed before the detail record(s) of both the authorization and deposit files. The merchant descriptor record cannot be sent in the middle of an order (e.g. between address records). A file may contain any number of merchant descriptor records, even one before every order.

Online only: Merchants must send the Merchant Descriptor Format Indicator (MD) for each transaction. Batch Only: Sending a merchant descriptor record causes Merchant Services to use the merchant descriptor record provided for every subsequent transaction within the file until another merchant descriptor record is found. For transactions that precede the first merchant descriptor record, the Transaction Division default value is used. For merchants who need to roll up several merchant names under one corporation, please contact your Merchant Services Representative for details on the use and regulations of the asterisk. If a merchant wishes to roll up several names into one company for chargeback and deposit activity purposes, ChaseNet ,Visa, and Visa Canadian Domestic Restricted Debit require that the company name must appear first and then be followed by an asterisk “*”. The asterisk may only appear in positions 5, 9 or 14 of the merchant descriptor record. An additional product description may then follow the asterisk using the remaining field positions. A sample worksheet can be found at the end of this Appendix.




Soft Merchant and Merchant Descriptor – Rules, (Continued)

Rules and Guidelines: (ECP Transactions) Merchant Descriptor is a batch-only function for ECP transactions.

The Automated Clearing House (ACH) uses two fields to describe the transaction to the accountholder. The Merchant Name, 15 bytes, always appears on the accountholder’s statement, and the Entry Description, 10 bytes, appears on the accountholder’s statement a majority of the time. Both are required fields.

A merchant must be approved by Merchant Services Risk/Credit department to enable Soft Merchant Name to be sent to the ACH.

When utilizing the merchant descriptor record, both the Soft Merchant Name and the Soft Entry Description are mandatory. If either field is sent as blank, both fields utilize the Transaction Division default values.

Merchant Services recommends that the Merchant Name be used for the Doing Business As (DBA) description and the Entry Description be used for the product description.

Not applicable to facsimile draft transactions.

In batch processing, the merchant descriptor records must be placed before the detail record(s) of both the authorization and deposit files. The merchant descriptor record cannot be sent in the middle of an order (e.g. between address records). A file may contain any number of merchant descriptor records, even one before every order.

Sending a merchant descriptor record causes Merchant Services to use the merchant descriptor record provided for every subsequent transaction within the file until another merchant descriptor record is found. For transactions that precede the first merchant descriptor record, the Transaction Division default value is used.




American Express

Authorizations If the online Soft Merchant Information Format Indicators SM, S2, S3, or S4, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002, or SM003) is sent, the information is sent to American Express.

If the online Merchant Descriptor Format Indicator (MD) or the batch Merchant Descriptor Record ("M" – Record) is sent, it is ignored.

Soft Merchant fields are handled differently dependent upon how the merchant is identified in the Merchant Services system. There are three categories a merchant falls into:

• Oil Industry • Aggregator • Other

The sections that follow outline each category and define what fields are used by those categories.

Oil Industry Merchants:

Fields sent to American Express

• MCC: located on the online Format Indicators SM, R2, S2, S3, or S4, or the batch Information Record IOI or the batch Product Record: Soft Merchant Information 2 (SM002). If it is not populated, the transaction division default value is sent to American Express.

If the MCC field on any of the online format indicators is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o MCC from S4 Format Indicator o MCC from S3 Format Indicator o MCC from S2 Format Indicator o MCC from R2 Format Indicator o MCC from SM Format Indicator

If the MCC field on any of the batch records is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o MCC from SM002 o MCC from IOI




American Express, (Continued)

Authorizations, (Continued)

Oil Industry Merchants, (Continued):

Fields sent to American Express, (Continued)

• Postal Code

If the Postal Code field is not populated, the transaction division default value is used.

• Merchant ID or Merchant/Seller ID

This field should be populated, and the value of the field must equal 11 bytes or the transaction rejects with Response Reason Code 225 (Invalid Field Data). If the field contains an 11-byte value, this value is sent to American Express.

If the Merchant ID or Merchant/Seller ID field on any of the online format indicators is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o Merchant/Seller ID from S4 Format Indicator o Merchant/Seller ID from S3 Format Indicator o Merchant/Seller ID from S2 Format Indicator o Merchant ID from SM Format Indicator

If the Merchant ID or Merchant/Seller ID field on any of the batch records is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o Merchant/Seller ID from SM002 o Merchant ID from SM001

Note: Backslash (\) should not be sent in any of these fields. If sent, American Express may decline the transaction, as the character is not allowed.

Fields not sent to American Express

• DBA • Merchant Contact Information • Street • City • Region • Country Code • Email Address • Telephone Number





Authorizations, (Continued): Aggregators: Online Format Indicators S2, S3, or S4, or batch Product Records SM001, SM002, or SM003 must be sent or the transaction rejects with Response Reason Code 227 (Missing Companion Data).


• DBA (only the first 19 alphabetic and numeric bytes) • Email Address: located on the Format Indicators S3 or S4, or the

batch Product Records SM001 or SM003. If the Email Address field on any of the online format indicators is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o Email Address from S4 Format Indicator o Email Address from S3 Format Indicator

If the Email Address field on any of the batch product records is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o Email Address from SM003 o Email Address from SM001

• Telephone Number/Contact Telephone Number: located on the Format Indicators S3 or S4.

If the Telephone Number/Contact Telephone Number fields on any of the online format indicators is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o Contact Telephone Number from S4 Format Indicator o Telephone Number from S3 Format Indicator

• Merchant Contact Information from SM001





Authorizations, (Continued): Aggregators: (Continued)

Fields sent to American Express, (Continued)

The following fields must be populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data):

• Street (only the first 20 bytes are used) • Postal Code • MCC • Merchant/Seller ID (all 20 alphabetic and numeric bytes bytes)

If any of the above fields, located on the online Format Indicators R2 and SM or the batch SM001 and IOI records, are sent, they are ignored.

Examples of populating CARD ACCEPTOR NAME/LOCATION in authorization message Merchant Services sends to American Express:

• All 20 alphabetic and numeric bytes of the Merchant/Seller ID • First 19 alphabetic and numeric bytes of the DBA. • Fields are separated with ‘*’.

Merchant/Seller ID: SELLER 1234-AB567890 DBA: AGGEGATOR * ACTUAL SELLER NAME

Example of SELLER_ID sent to American Express: 34AB567890*AGGEGRATORACTUALSEL

Note: Backslash (\) should not be sent in any of these fields. If sent, American Express may decline the transaction, as the character is not allowed.

Fields not sent to American Express

• City • Region





Authorizations, (Continued): Other Merchants: Fields referenced in this section are located on the online Format Indicators SM, S2, S3, or S4, or batch Product Records SM001, SM002, or SM003

Fields sent to American Express o MCC: located on the online Format Indicators SM, R2, S2, S3, or

S4, or the batch Information Record IOI or the batch Product Record: Soft Merchant Information 2 (SM002).

If it is not populated, the transaction division default value is sent to American Express.

If the MCC field on any of the online format indicators is populated for the transaction, the precedence of the following fields, from highest to lowest, is:


If the MCC field on any of the batch records is populated for the transaction, the precedence of the following fields, from highest to lowest, is:

o MCC from SM002 o MCC from IOI

Fields not sent to American Express o DBA o Merchant Contact Information o Street o City o Region o Postal Code o Country Code o Email Address o Telephone Number o Merchant ID or Merchant/Seller ID





Deposits Oil Industry and Other Merchants: If the batch Product Record: Soft Merchant Information 1, 2, or 3 (SM001, SM002, SM003) is sent, the information is sent to American Express.

If the batch Merchant Descriptor Record (“M”- Record) is sent, the information is sent to American Express.


• MCC If populated, it is ignored, and the authorization MCC value is sent to American Express.

• DBA If multiple soft merchant information fields are populated for the transaction, the precedence from highest to lowest is:

o DBA (Product Record SM001) o Soft Merchant Name and/or Item Description ("M" – Record) o Transaction Division default value

• City

If multiple soft merchant information fields are populated for the transaction, the precedence from highest to lowest is:

o City (Product Record SM002) o Soft Merchant City/Customer Service Phone Number

("M" – Record) o Transaction Division default value

• Street If not populated the transaction division default value is sent to American Express.

• Region If not populated the transaction division default value is sent to American Express.

• Postal Code If not populated the transaction division default value is sent to American Express.

• Country Code If not populated the transaction division default value is sent to American Express.

• Merchant ID or Merchant/Seller ID If not populated the transaction division default value is sent to American Express.





Deposits, (Continued): Aggregators: If the batch Product Record: Soft Merchant Information 1, 2, or 3 (SM001, SM002, or SM003) is sent, the information is sent to American Express.

If either of the Product Records: Soft Merchant Information 1 or 2 (SM001 and SM002) are missing, the transaction rejects with Response Reason Code 227 (Missing Companion Data).

If any of the fields, located on the batch IOI records or M-Record, are sent, they are ignored.


• Merchant/Seller ID: located on the batch Product Record SM002, is required when the transaction division is identified as Aggregator or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Merchant Services sends this field to American Express in American Express’ SELLER_ID field in the Location Detail record.

• DBA: American Express requires that Aggregators use their aggregator business name in conjunction with the name of the actual seller. This field must be populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data). Merchant Services sends this field to American Express in American Express’ LOCATION_NAME field in the Location Detail record.

The following fields must be populated or the transaction rejects with Response Reason Code 225 (Invalid Field Data):

• DBA • City • Region • Postal Code • Country Code • Merchant/Seller ID • MCC




Discover, Discover Diners, and JCB for U.S. Merchant Processing U.S. Currency

Authorizations If the online Soft Merchant Information Format Indicators SM, S2, or S3, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to Discover.

If the online Merchant Descriptor Format Indicator MD or the batch Merchant Descriptor Record ("M" – Record) is sent, the information is sent to Discover.

Fields sent to Discover

• Street • City • Region • Postal Code • MCC: located on the online Format Indicators SM, R2, S2, S3, or S4,

or the batch Information Record IOI. If the MCC field on two or more of the online format indicators are populated for the transaction, the precedence from highest to lowest is:


If it is not populated, the transaction division default value is sent to Discover.




Discover, Discover Diners, and JCB for U.S. Merchant Processing U.S. Currency (Continued)


Fields sent to Discover, (Continued)

• DBA: located on the online Format Indicators SM, S2, S3, or S4, or the batch Product Record SM001. If multiple soft merchant information fields are populated for the transaction, the precedence from highest to lowest is:

o DBA from S4 Format Indicator o DBA from S3 Format Indicator o DBA from S2 Format Indicator o DBA from SM Format Indicator o DBA from SM001 o Soft Merchant Name and/or Item Description (Format

Indicator MD or "M" – Record) o Transaction Division default value


• Merchant Contact Information (Product Record SM001) if sent as a valid phone number, URL, or email address

• Soft Merchant City/Customer Service Phone Number (Format Indicator MD or "M" – Record) if sent as a valid phone number, URL, or email address

• City from S4 Format Indicator • City from S3 Format Indicator • City from S2 Format Indicator • City from SM Format Indicator • City from SM002 • Merchant City/Customer Service Phone Number (Format Indicator

MD or "M" – Record) if sent as a city • Transaction Division default value

Fields not sent to Discover

• Merchant ID




Discover, Discover Diners, and JCB for U.S. Merchant Processing U.S. Currency, (Continued)

Deposits If the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to Discover.

If the batch Merchant Descriptor Record ("M" – Record) is sent, the information is sent to Discover.

Fields sent to Discover

• Street • City • Region • Postal Code • MCC: located on the batch Information Record IOI, is populated and

if a valid authorization is found in the Merchant Services Prior Order Database (PODB), or MCC is sent in the Discover Extension Record (DI001), the Discover Diners Extension Record (DD001), or the Japan Credit Bureau Extension Record (JC001), the value used at authorization time is sent to Discover.

If an authorization is not found in the Merchant Services PODB, the MCC value sent with the transaction at deposit time is sent to Discover.

If the MCC field is not populated in the deposit transaction and if an authorization is not found in the Merchant Services PODB, and if MCC is not sent in the Extension Record (DI001), (DD001), or (JC001), the transaction division default value is sent to Discover. The precedence from highest to lowest is:

o MCC used at auth time (from PODB or Extension Record DI001, or DD001, or JC001)

o MCC sent at deposit time o MCC from the transaction division default




Discover, Discover Diners, and JCB for U.S. Merchant Processing U.S. Currency, (Continued)

Deposits, (Continued) Fields sent to Discover, (Continued)

• DBA: located on the batch Product Record SM001.




• Merchant Contact Information (Product Record SM001) if sent as a valid phone, number, URL, or email address

• Soft Merchant City/Customer Service Phone Number ("M" – Record) if sent as a valid phone number, URL, or email address

• City (Product Record SM002) • Merchant City/Customer Service Phone Number ("M" – Record) if

sent as a city • Transaction Division default value

Fields not sent to Discover

• Merchant ID




JCB (Non-U.S. Merchants Processing Non-U.S. Currency)

Authorizations For U.S. merchants processing U.S. currency, JCB follows the Discover rules. Please refer to the Discover section of this appendix for further details.

If the online Soft Merchant Information Format Indicators SM, S2, or S3, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, it is ignored.

If the online Merchant Descriptor Format Indicator MD or the batch Merchant Descriptor Record ("M" – Record) is sent, that information is sent to JCB.

If the MCC field (located on the online Format Indicator R2 or the batch Information Record IOI is populated, the value is sent to JCB. If it is not populated, the transaction division default value is sent to JCB.

Deposits

For U.S. merchants processing U.S. currency, JCB follows the Discover rules. Please refer to the Discover section of this appendix for further details.

If the online Soft Merchant Information Format Indicators SM, S2, or S3, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, it is ignored.

If the batch Merchant Descriptor Record ("M" – Record) is sent, that information is sent to JCB.

If the MCC field, located the batch Information Record IOI, is populated and if a valid authorization is found in the Merchant Services Prior Order Database (PODB), or MCC is sent in the Japanese Credit Bureau (JCB) Extension Record (JC001), the value used at authorization time is sent to JCB.

If an authorization is not found in the Merchant Services PODB, the MCC value sent with the transaction at deposit time is sent to JCB.

If the MCC field is not populated in the deposit transaction and if an authorization is not found in the Merchant Services PODB, and if MCC is not sent in the JCB Extension Record (JC001), the transaction division default value is sent to JCB. The precedence from highest to lowest is:

• MCC used at auth time (from PODB or Extension Record JC001) • MCC sent at deposit time • MCC from the transaction division default




International Maestro, MasterCard, and MasterCard Canadian Restricted Debit

Authorizations If the online Soft Merchant Information Format Indicators SM, S2, or S3, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

If the online Merchant Descriptor Format Indicator MD or the batch Merchant Descriptor Record ("M" – Record) is sent, the information is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

Fields sent to International Maestro, MasterCard, or MasterCard Canadian Restricted Debit

• City • Region • Postal Code • Merchant/Seller ID • MCC: located on the online Format Indicators SM, R2, S2, S3, or S4,

or the batch Information Record IOI. If the MCC field on two or more of the online format indicators are populated for the transaction, the precedence from highest to lowest is:


If it is not populated, the transaction division default value is sent to International Maestro MasterCard or MasterCard Canadian Restricted Debit.




International Maestro, MasterCard, and MasterCard Canadian Restricted Debit (Continued)


Fields sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit, (Continued)









Fields not sent to International Maestro, MasterCard, or MasterCard Canadian Restricted Debit

• Street • Country Code




International Maestro, MasterCard, and MasterCard Canadian Restricted Debit (Continued)

Deposits If the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

If the batch Merchant Descriptor Record ("M" – Record) is sent, the information is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

Fields sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

• Street • City • Region • Postal Code • Merchant/Seller ID • MCC: located on the batch Information Record IOI, is populated and

if a valid authorization is found in the Merchant Services Prior Order Database (PODB), or MCC is sent in the International Maestro Extension Record (IM001) or the MasterCard Extension Record (MC001), the value used at authorization time is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

If an authorization is not found in the Merchant Services PODB, the MCC value sent with the transaction at deposit time is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit.

If the MCC field is not populated in the deposit transaction and if an authorization is not found in the Merchant Services PODB, and if MCC is not sent in the Extension Record (IM001) or (MC001), the transaction division default value is sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit. The precedence from highest to lowest is:

o MCC used at auth time (from PODB or Extension Record IM001 or MC001)





International Maestro, MasterCard, and MasterCard Canadian Restricted Debit, (Continued)

Deposits, (Continued) Fields sent to International Maestro, MasterCard or MasterCard Canadian Restricted Debit, (Continued)












ChaseNet , Visa, and Visa Canadian Domestic Restricted Debit

Authorizations If the online Soft Merchant Information Format Indicators SM, S2, or S3, or the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

If the online Merchant Descriptor Format Indicator MD or the batch Merchant Descriptor Record ("M" – Record) is sent, that information is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

Fields sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit

• City • Region • Postal Code • MCC: located on the online Format Indicators SM, R2, or S2 or S3, or

the batch Information Record IOI. If the MCC field on two or more of the online format indicators are populated for the transaction, the precedence from highest to lowest is:


If it is not populated, the transaction division default value is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.




ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit, (Continued)


Fields sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit, (Continued)









Fields not sent to ChaseNet, Visa and Visa Canadian Domestic Restricted Debit

• Merchant ID • Street





Deposits If the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

If the batch Merchant Descriptor Record ("M" – Record) is sent, the information is sent to Visa and Visa Canadian Domestic Restricted Debit.

Fields sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit

• Street • City • Region • Postal Code • MCC: located on the batch Information Record IOI, is populated and

if a valid authorization is found in the Merchant Services Prior Order Database (PODB), or MCC is sent in the Visa Extension Record (VI001), ChaseNet Signature Debit/Prepaid Extension Record (CR001), or ChaseNet Credit Extension Record (CZ001) the value used at authorization time is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

If an authorization is not found in the Merchant Services PODB, the MCC value sent with the transaction at deposit time is sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit.

If the MCC field is not populated in the deposit transaction and if an authorization is not found in the Merchant Services PODB, and if MCC is not sent in the Extension Record (VI001, CR001, CZ001), the transaction division default value is sent to ChaseNet, Visa, Visa Canadian Domestic Restricted Debit. The precedence from highest to lowest is:

o MCC used at auth time (from PODB or Extension Record VI001, CR001, CZ001)






Deposits, (Continued) Fields sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit, (Continued)









Fields not sent to ChaseNet, Visa, and Visa Canadian Domestic Restricted Debit

• Merchant ID




PINless, PIN-Debit and Electronic Benefits Transfer (EBT)

Authorizations If the online Soft Merchant Information Format Indicators SM, S2, or S3 is sent, the information is sent to the Debit and EBT Networks.

If the online Merchant Descriptor Format Indicator MD is sent, the information is sent to Debit and EBT Networks.

Fields sent to the Debit and EBT Networks

• Merchant/Seller ID • Street • City • Region • Postal Code • Country Code • Food and Consumer Number (FCN) • DBA: located on the online Format Indicators SM, S2, S3, or S4, or

the batch Product Record SM001. If multiple soft merchant information fields are populated for the transaction, the precedence from highest to lowest is:



• MCC: located on the online Format Indicators SM, R2, S2, S3, or S4. If the MCC field on two or more of the online format indicators are populated for the transaction, the precedence from highest to lowest is:


If it is not populated, the transaction division default value is sent to the Debit and EBT Networks.




PINless, PIN-Debit and Electronic Benefits Transfer (EBT), (Continued)

Deposits If the batch Product Record: Soft Merchant Information 1 or 2 (SM001, SM002) is sent, the information is ignored.

If the batch Merchant Descriptor Record ("M" – Record) is sent, the information is ignored.





Appendix S: PayPal

Soft Merchant Information Card Types / Supported Currencies

American Express / All currencies for Authorization and Settlement ChaseNet / U. S. Dollars Discover and Discover Diners / All currencies International Maestro / All currencies JCB for U.S. merchants / U.S. Dollars MasterCard / All currencies MasterCard Canadian Domestic Restricted Debit / Canadian Dollars PIN-Debit and EBT / U.S. Dollars PINless Debit / U.S. Dollars Visa / All currencies Visa Canadian Domestic Restricted Debit / Canadian Dollars

Merchant Descriptor Card Types / Supported Currencies

American Express / All currencies for Settlement ChaseNet / U. S. Dollars Discover and Discover Diners / All currencies Electronic Check Processing (does not include EUDD) / All currencies International Maestro / All currencies JCB / All currencies MasterCard / All currencies MasterCard Canadian Domestic Restricted Debit / Canadian Dollars PayPal / U.S. Dollars PIN-Debit and EBT / U.S. Dollars PINless Debit / U.S. Dollars Visa / All currencies Visa Canadian Domestic Restricted Debit / Canadian Dollars






APPENDIX T: SOFT MERCHANT INFORMATION AND MERCHANT DESCRIPTOR, (Continued) Sample Batch Worksheet

If you plan on using the Asterisk to roll up several merchant names for Visa regulations, please use this sample record layout when constructing the information format.

M * M * M *

Template Notes: If “*” is not used – can only have the company name (no product descriptor) Before “*” – abbreviated corporate name After “*” – product name, product type, installment information (i.e. 1 of 4), etc.

Sample Online Worksheet

For a sample of the Online Format refer to the Merchant Descriptor Format Indicator MD in the Online Processing Format Specification.


APPENDIX U: TEST ENVIRONMENT How It Works Merchant Services’ test environment enables merchants, submitters, and

software vendors to use any valid account number in the test environment to simulate all of Merchant Services’ response codes for:

• Approvals • Declines • Address Verification Services (AVS) • Card Security Value (CSV) • Authentication Value (Verified by Visa/MasterCard SecureCode)

The responses are based on specific data sent in with the transactions.

Test card numbers do not need to be provided by Merchant Services for merchants, submitters, and software vendors to test the full suite of responses that are possible for all transaction types.

Merchant Services performs front-end edits before a test system simulation is performed.

While the certification system is available for testing at all hours, it is only monitored for availability during business hours (8:00am EST – 5:30pm EST Monday – Friday). In addition, the hardware in place is designed primarily for certification testing, not load testing. Please reach out to your Integration Consultant to discuss any additional testing requirements or questions.


For Debit and Gift Card Methods of Payment, the Response Reason Code is based on the cents value in the Amount field submitted on the transaction.

For all other methods of payment, the Response Reason Code is based on the whole dollar value in the Amount field, submitted on the transaction. Whole dollar value is defined as a value between and including $100.00 and $999.99 where only the three positions to the left of the decimal are used for Response Reason Code determination.

Address Verification Response Code

The AVS Response Code is based on the zip/postal code value, in conjunction with the Method of Payment (MOP) value, submitted on the transaction.

For American Express Enhanced AVS, the AVS Response Code is based on specific name and address values submitted on the transaction.



APPENDIX U: TEST ENVIRONMENT (Continued)

Card Security Value Response Code

The Card Security Value (CSV) Response Code is based on the card security presence and card security values, in conjunction with the Method of Payment (MOP) value, submitted on the transaction.

Cardholder Authentication

Verified by Visa The Cardholder Authentication Verification Value (CAVV) Response Code is based on the tenth (10th) character of the CAVV value submitted on the transaction.

International Maestro and MasterCard There is no separate response code returned by the issuing bank based on the Accountholder Authentication Value (AAV) like there is for Verified by Visa. Instead, if the AAV is a non-match value, the issuing bank declines the transaction.

To simulate a non-match of the AAV code, populate the Amount field with a decline Response Reason Code.

Partial Authorizations

Partial Authorizations can be tested for multiple Methods of Payment (MOP). Specific test account numbers must be used and are provided by the Certification Analyst.

Bill Me Later BillMeLater, the company, is involved in all product testing. BillMeLater’s

Integration Analyst provides a test script for certification.

ChaseNet All new submitter and software vendor certifications must validate the ability to

handle all current ChaseNet methods of payment. Please speak with your Merchant Services Representative to discuss using test divisions.

PayPal PayPal testing validates transaction formats.

The test environment always returns a shipping address regardless of the value sent in the No Shipping Address Display field, located on URL and Address Flag Format Indicator (US).

The customer redirect process, which is part of Express Checkout, is validated during the production test with PayPal.



APPENDIX U: TEST ENVIRONMENT (Continued)



Appendix B: Address Verification


Appendix G: Partial Authorization

Appendix H: Verified by Visa

Appendix I: Mastercard SecureCode

Appendix S: PayPal

Appendix AL: ChaseNet

To Get Started

Contact your Merchant Services Representative to receive a copy of the test system simulation documents.


APPENDIX V: LEVEL 2 AND LINE ITEM LEVEL DATA

This product is not supported in the Online Processing Format Specification


APPENDIX W: AMERICAN EXPRESS Introduction Merchant Services supports American Express Card Acceptor Network

(CAPN).

Card Acceptor Network (CAPN)

For American Express CAPN authorizations, see Appendix T: Soft Merchant Information and Merchant Descriptor for more information.

American Express requires extended authorization data at deposit time. For merchants that authorize with Merchant Services, the extended authorization data is stored at Merchant Services and is used at deposit time. For merchants who authorize elsewhere, Extension Record: American Express 3 (EAX003) must be sent at deposit time.

For American Express, Merchant Services supports Corporate Purchasing Solutions (CPS) Level 2 and enhanced Transaction Advice Addendum (TAA). This is not supported for non-U.S. currency transactions.

As part of CAPN, American Express has created new TAA records to allow for more detail to be passed on transactions sent to American Express with certain industry segments. The following records are used to support CAPN:

• Location Detail (Required for American Express Aggregator merchants) See Appendix T: Soft Merchant Information and Merchant Descriptor for more information. o Product Record: Soft Merchant Information 1 (PSM001) o Product Record: Soft Merchant Information 2 (PSM002)

• Industry Specific Detail o Lodging

Product Record: Lodging 1 (PLG001) Product Record: Lodging 2 (PLG002)

o Insurance Product Record: Insurance Information 1 (PIN001) Product Record: Insurance Information 2 (PIN002)



APPENDIX W: AMERICAN EXPRESS, (Continued) Card Acceptor Network (CAPN), (Continued)

o Entertainment/Ticketing Product Record: Entertainment/Ticketing Information 1

(PET001) Product Record: Entertainment/Ticketing Information 2

(PET002) o Retail

Product Record: American Express Line Item Level Data Record #1 (PRA001)



o CPS Level 2 Detail Product Record: American Express CPS Level 2 – Line

Item Level Data (PP3) Note: If this record is sent for non-U.S. currency American Express transactions, Merchant Services ignores it.

American Express has specific mandates in terms of what TAA records may be delivered at the time of deposit. Merchant Services does not allow multiple product records of the same product type and/or sequence number. For example, do not send two Product Record: Lodging 1 (PLG001) or the transaction rejects with Response Reason Code 204 (Other Error).

The following TAA record combinations can be sent to American Express: • CPS Level 2 Detail • Industry Specific Detail except Retail • Location Detail

OR • Industry Specific Detail for Retail • Location Detail

If both CPS Level 2 Detail and Retail Information are sent, the Retail Information is ignored.

Only one industry specific product record type is sent to American Express. The merchant should only send one industry specific product record type that applies to the transaction division.



APPENDIX W: AMERICAN EXPRESS, (Continued)


Appendix T: Soft Merchant Information and Merchant Descriptor Appendix V: Level 2 and Line Item Level Data


U.S., Canada, and some international currencies

Legacy For merchants, who do not wish to use the new Merchant Services product records, American Express and JCB allows the use of four Transaction Advice Addendum (TAA) records with each settlement item so that an American Express merchant has the ability to provide an American Express accountholder with additional detailed descriptive transaction information. Typically these four, 40-byte fields are maintained within Merchant Services’ merchant database at an American Express Service Establishment level and if present, are appended by Merchant Services to each settlement transaction submitted by a merchant. The implementation outlined in Extension Record: American Express 1 (EAX001) and Extension Record: American Express 2 (EAX002) Extension Record: JCB 2 (EJC002) and Extension Record: JCB 3 (EJC003) allows a merchant to submit the four TAAs with each and every transaction. This allows a merchant flexibility at a transaction level rather than a Service Establishment level. If the TAAs are not submitted, Merchant Services utilizes the Transaction Division default values.

If only populating one TAA field, TAA1 must be populated.

If populating three TAAs, the blank TAA must be sent in field TAA4.

For non-U.S. currency transactions, these TAA records can only be used for retail transactions. Only the first 19 characters of each TAA field are sent to American Express and JCB. The ship to postal code is required by American Express when sending these records. If ship to address is not sent, Merchant Services sends the Merchant’s postal code to American Express and JCB.

The ship to postal code can be sent in the Formatted Address Record: Ship To Address (HA), Address Record (AS), or Product Record: Procurement Level 2 and Line Item Level Data (PPC001).

: Ship To Address (HA), Address Record (AS), or Product Record: Procurement Level 2 and Line Item Level Data (PPC001).


APPENDIX W: AMERICAN EXPRESS, (Continued)

Authorization Response Codes

Appendix A: Response Reason Code Description/Usage.

To Get Started



APPENDIX X: ELECTRONIC CHECK PROCESSING (ECP) Introduction Electronic Check Processing (commonly referred to as eCheck or ECP) is an

electronic payment solution designed to streamline payments in the U.S. and Canada. Electronic check processing directly debits bank accounts for payment of goods or services or both. For additional information about Merchant Services’ eCheck solutions and an overview of the rules and regulations governing eCheck transactions, please refer to the ECP Merchant User Guide, Best Practice Guide, Know Your Customer slide deck, and eCheck Supplemental Sample Kit.

In this appendix, when referring to authorizations, the open to buy is not checked and funds are not held for the transaction.

The Merchant Services eCheck product is designed to provide merchants with a robust suite of eCheck services and risk and exception management tools. All of these are critical to operating a profitable and efficient eCheck program. Merchant Services offers the following authorization methods to all merchants processing eCheck:

• Internet (WEB) - Accept eCheck payments from customers via the WEB or wireless device

• Call Center Payments (TEL) - Accept eCheck payments from customers via the Call Center

• Account Receivable Conversion (ARC) - Supports the conversion of checks received via U.S. mail into a merchant’s unattended lockbox

• Point of Purchase Conversion (POP) - Supports single entry debits used at the point of purchase

• Corporate Credit or Debit (CCD) - Supports the use of ACH debits and credits in Business to Business (B2B) transactions

• Single and Recurring Payments (PPD) - Supports a merchant’s recurring billing program

Merchants are contractually obligated to ensure they are in compliance with the appropriate rules and regulations related to processing ACH transactions such as NACHA, REG E, Fair Credit Reporting Act (FCRA), etc. Please refer to ECP Merchant User Guide, Best Practice Guide, Know Your Customer slide deck, and eCheck Supplemental Sample Kit for details.



APPENDIX X: ELECTRONIC CHECK PROCESSING (ECP), (Continued)

How It Works EChecks authorization-only transactions can be processed online or batch.

Deposit transactions are processed in batch only. eChecks are processed in one of two ways for U.S. Dollar transactions:

• Automated Clearing House (ACH) network when the bank is a member

• Facsimile draft at the direction of the merchant or when the consumer’s bank is not a participant of the ACH network

NACHA rules state the Company Name and Description must be clearly defined in the transaction. This information is printed on the consumer bank statement. This information is part of the transaction division default, but can be overridden on the individual transaction.

Validation Merchant Services sends all eCheck transactions through the validation process once front-end edits have been performed on the transaction. Validation is mandatory for the merchant and utilizes three database checks:

• Notification of Change (NOC) file: looks for changes made to any account data

• Federal Reserve and Accuity Epic Ware ABA file: ensures that the routing number belongs to a legitimate financial institution and that they participate in ACH

Note: If the account number is not in this file, the transaction rejects with either Response Reason Code 751 (Transit Routing Number Unknown) or Response Reason Code 760 (ACH Non-Participant).

• Internal Proprietary Negative file: looks for negative account history provided by the customer's bank

Note: If the account number is not in this file, the transaction rejects with a Response Reason Code in the range of 750-769 or 834. These Response Reason Codes are detailed in Appendix A: Response Reason Code Description/Usage and the ECP Merchant User Guide.

Deposit and Refund Only transactions that have passed validation are forwarded to the ACH network to be deposited or refunded.




ECP - Advanced Verification When the validation process completes successfully, Merchant Services Merchants can further verify their eCheck transactions against the National Shared DatabaseSM hosted by Early Warning Systems. This is done by invoking the ECP – Advanced Verification product using the following action codes:

Action Code

Description

W1 Validate/ Account Status Verification W3 Validate/ Account Status Verification / Account

Owner Authentication W4 Validate / Account Status Verification / Deposit W5 Validate / Account Status Verification / Account

Owner Authentication / Deposit W6 Validate/Account Status Verification/Refund W7 Validate/Account Status Verification/Account

Owner Authentication/Refund W8 Validate/Account Status Verification/Pre-Note W9 Validate/Account Status Verification/Account

Owner Authentication/Pre-Note

Providing the merchant is domiciled in the US and is properly enabled, using these action codes, the merchant can request to do either of two services:

1. Account Status Verification, or 2. Account Status Verification with Account Owner Authentication

Account Status Verification: Confirms that the bank routing number and account number are valid. This service uses the Account Number field from the Online Processing Detail Record or the Detail Record (“S” Input), along with the RDFI/Bank ID from either

• The Electronic Check Processing Format Indicator (EC) or • The Extension Record: Electronic Check Processing (EEC001) to inquire into the National Shared DatabaseSM hosted by Early Warning Systems.





ECP - Advanced Verification, (Continued) When the ECP Authorization Method field is equal to A or P (ARC or POP) the Check Amount and Check Serial Number fields are required. The check serial number can be found on the ECP Advanced Verification Format Indicator (AV02) or the Extension Record: Electron Check Processing (EEC001) record. If the Merchant is properly enabled, additional account status information is returned in the ECP Advanced Verification Reply Format Indicator (AV) or the Product Record: ECP Advanced Verification Response (PRE001). The Account Status Codes determine a positive or negative outcome as reflected in the Response Reason Code field of the Online Processing Return Format Record or the “S” Record Output. The Account Status Codes are listed as follows:

Account Status Codes: Description

Account Status Codes: Description

000 Not Located 084 Participant Broker Check

002 Closed for Cause 096 No Known Information

003 Closed for Cause/Purged 098 Non-DDA

006 Stop Payment ¾ Individual 099 Present

007 Stop Payment ¾ Range 102 Savings Closed for Cause

010 Post No Debits 103 Savings Closed for Cause/ Purged

012 Closed 106 Savings Stop Payment ¾ Individual

013 Closed/Purged 107 Savings Stop Payment ¾ Range

014 Pending Closed 110 Savings Post No Debits

015 Return Item Account 112 Savings Closed

020 Enhanced OD 113 Savings Closed/Purged

021 Enhanced OD 114 Savings Pending Closed

022 Enhanced OD 199 Savings Present

080 Credit Card Check 430-499 High Probability of Return

081 Participant Line of Credit Check 699 Open Valid

082 Participant Home Equity Check





ECP - Advanced Verification, (Continued) Account Owner Authentication

Determines if the accountholder (consumer) information provided by the merchant matches the accountholder information of the account. The Account Status Verification is combined with the Account Owner Authentication, a verification of the account owner information is conducted. The account owner data provided by the merchant for a consumer or business is submitted with the transaction in either:

• ECP Advanced Verification Format Indicators AV01, AV02, AV03 and AV04 or

• Product Records: ECP Advanced Verification 1, 2, 3, 4, and 5 (PAV001, PAV002, PAV003, PAV004 and PAV005).

This data is matched against account owner data on the National Shared DatabaseSM.

Account Owner Authentication can only be performed when you do Advanced Verification.

Account Owners Business Name Matching If both the account owner business name and the account owner name (along with the other account owner matching fields) are to be verified, the merchant must send in two separate transactions.

o A transaction having the business name along with other business related data elements for matching (Address, TIN etc).

o A transaction having the account owner’s personal name along with other personal related data elements for matching (SSN, DOB etc.).

The Early Warning System is not able to distinguish between personal and business data elements. Therefore, when both the personal name and business name are submitted along with other Account Owner fields, the transaction rejects with Response Reason Code 225 (Invalid Field Data).





ECP - Advanced Verification, (Continued)

Account Owner Condition Codes/ Account Owner Match Codes

If the merchant is properly enabled an Account Owner Condition Code is returned along with one or more Account Owner Match Codes in the ECP Advanced Verification Reply Format Indicator (AV) or the Product Record: ECP Advanced Verification Response (PRE001). The Account Owner Condition Codes are listed as follows:

AOA Condition

Codes: Description 000 Normal return - no system errors 300 Valid ABA, not an Early Warning participant

301 Valid ABA, not an Early Warning AOA contributor*

302 Valid participant, but AOA data unavailable

304 Missing account owner name 396 No known information 900 No account owner response requested or provided

901 No account owner response requested or provided

*A Contributor is a financial entity that provides Bank Account Owner Information along with Bank Account Status information on a timely basis to the National Shared DatabaseSM.

The following is a list of Account Owner Match Codes along with a description of each:

Match Codes: Description

Y The inquiry field closely or exactly matches the database

C

The inquiry field conditionally (particularly) matches the database (see descriptions and examples for each element).

N The inquiry field does not match the database.

U No identifying data is available in the database for the account provided.

If an Account Owner Condition Code other than 000 is returned then no Account Owner Match codes are returned and the Merchant is not billed for the attempted verification.





ECP - Advanced Verification, (Continued) When the Account Owner Condition Code is equal to 000 an Account Owner Match Code is returned for each Account Owner data field submitted for authentication. These codes indicate whether the data supplied by the Merchant matches the data in the National Shared DatabaseSM as described above. The transaction is declined with a Response Reason Code 575 (ECP Account Verification/AOA Decline) when any of the following Account Owner Match Code values are returned on the ECP Advanced Verification Reply Format Indicator (AV) or Product Record: ECP Advanced Verification Response Message (PRE001) for the following fields:

Account Owner Match Code

AOA Match Field

N SSN or TIN Match

N DOB Match

N or U Name Match

Blank N or U Name Match Business Match

For more information on Match Codes and AOA Matching see ECP Advanced Verification User Guide and AOA Product Mapping Guide.

Deposit and Refund Only transactions that have passed validation and, optionally verification are forwarded to the ACH network to be deposited or refunded.

POP/ARC Transactions

Merchant Services supports both POP (Point of Purchase) and ARC (Accounts Receivable) conversion transactions.




Transaction Types and Requirements – Non POP/ARC Transactions

Validate Only - Validates this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. Online Request:


a. Action Code = LO

b. MOP = EC

c. Amount = all zeros

2. Format Indicator

a. Electronic Check Processing (EC)

Response:


Batch Request:


a. Action Code = LO

b. MOP = EC


2. Extension Record

a. Electronic Check Processing (EEC001)

i. Account Type

Response:





Transaction Types and Requirements – Non POP/ARC Transactions, (Continued)

Validate and Deposit this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, deposit the transaction. Batch Request:


a. Action Code = DO

b. MOP = EC

2. Extension Record


i. Account Type

3. Formatted Address Record

a. ECP and European Direct Debit (KA)

4. Address Record

a. ECP and European Direct Debit (AM)

Response:






Validate and Refund this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, issue a credit to this account. Batch Request:


a. Action Code = ER

b. MOP = EC

2. Extension Record


i. Account Type

ii. Preferred Delivery Method



4. Address Record


Response:






Validate and Pre-Note (Credit) - Validate this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, pre-note this credit transaction. Batch Request:


a. Action Code = NC

b. MOP = EC


2. Extension Record




4. Address Record


Response:






Validate and Pre-Note (Debit) - Validate this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, pre-note this debit transaction. Batch Request:


a. Action Code = ND

b. MOP = EC


2. Extension Record




4. Address Record


Response:






Validate / Account Status Verification this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. Online Request:


a. Action Code = W1

b. MOP = EC

c. Amount = All zeroes

2. Format Indicator


Response:



a. ECP Advanced Verification (AV)

Note: Only returned if the merchant is properly enabled for the ECP Verification System.

Batch Request:


a. Action Code = W1

b. MOP = EC

c. Amount = all zeroes

2. Extension Record


Response:

1. S" Record Output Continued on next page



Transaction Types and Requirements – Non POP/ARC Transactions (Continued)

Validate / Account Status Verification with Account Owner Authentication this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM. Online Request:


a. Action Code = W3

b. MOP = EC


2. Format Indicator


b. ECP Advanced Verification 1 - (AV01)

i. First Name and Last Name

or

ii. Business Name

Note: Send First Name and Last Name or Business Name.

c. ECP Advanced Verification 2 - (AV02) (Optional)

d. ECP Advanced Verification 3 - (AV03) (Optional)

e. ECP Advanced Verification 4 - (AV04) (Optional)

Response:



a. ECP Advanced Verification Reply (AV) (Optional)






Validate / Account Status Verification with Account Owner Authentication, (Continued) Batch Request:


a. Action Code = W3

b. MOP = EC


2. Extension Record


3. Product Records

a. ECP Advanced Verification 1 - (PAV001)


or

b. ECP Advanced Verification 2 - (PAV002)

i. Business Name

Note: Send First Name and Last Name (PAV001) or Business Name (PAV002)

c. ECP Advanced Verification 3 - (PAV003) (Optional)

d. ECP Advanced Verification 4 - (PAV004) (Optional)

Response:


2. Product Record

a. ECP Advanced Verification Response Message (PRE001)





Transaction Types and Requirements – Non POP/ARC Transaction (Continued)

Validate / Account Status Verification/Deposit this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM Batch Request:


a. Action Code = W4

b. MOP = EC

2. Extension Record


i. Account Type\

3. Product Record

a. ECP Advanced Verification - (PAV001)


or

b. ECP Advanced Verification - (PAV002)

i. Business Name

Note: Send First Name and Last Name (PAV001) or Business Name (PAV002) c. ECP Advanced Verification 3 - (PAV003) (Optional)




5. Address Record


Response:

1. "S" Record Output Continued on next page



Transaction Types and Requirements –Non POP/ARC Transaction (Continued)

Validate / Account Status Verification with Account Owner Authentication/Deposit this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes deposit the transaction. Batch Request:


a. Action Code = W5

b. MOP = EC

2. Extension Record


i. Account Type

3. Product Record



or


i. Business Name





5. Address Record

a. ECP and European Direct Debit (AM) Continued on next page



Transaction Types and Requirements –Non POP/ARC Transaction (Continued)

Validate / Account Status Verification with Account Owner Authentication/Deposit, (Continued)

Response:


2. Product Record






Transaction Types and Requirements –Non POP/ARC Transactions (Continued)

Validate / Account Status Verification/Refund this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes issue a credit to this account. Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = W6 b. MOP = EC

2. Extension Record a. Electronic Check Processing (EEC001)

i. Account Type 3. Product Record


i. First Name and Last Name or

b. ECP Advanced Verification - (PAV002) i. Business Name



4. Formatted Address Record a. ECP and European Direct Debit (KA)

5. Address Record a. ECP and European Direct Debit (AM)

Response:


2. Product Record a. ECP Advanced Verification Response Message (PRE001)



PPENDIX X: ELECTRONIC CHECK PROCESSING (ECP), (Continued)

Transaction Types and Requirements –Non POP/ARC (Continued)

Validate / Account Status Verification with Account Owner Authentication / Refund is performed on the transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication (Account Owner Authentication) service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes, issue a credit to this account. Batch Request:


a. Action Code = W7

b. MOP = EC

2. Extension Record


i. Account Type

3. Product Records



or b. ECP Advanced Verification - (PAV002)

i. Business Name





5. Address Record





Validate / Account Status Verification with Account Owner Authentication / Refund, (Continued): Batch Response:


2. Product Record






Validate / Account Status Verification / Pre-Note this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes, send a pre-note to the customer’s bank. Batch Request:


a. Action Code = W8

b. MOP = EC

c. Amount = All zeroes

2. Extension Record


3. Product Record



or


i. Business Name





5. Address Record





Validate / Account Status Verification / Pre-Note, (Continued)

Batch

Response:

1. "S" Record Output 2. Product Record






Validate / Account Status Verification with Account Owner Authentication / Pre-Note is performed on the transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes, send a pre-note to the customer’s bank. Batch Request:


a. Action Code = W9

b. MOP = EC


2. Extension Record


3. Product Record




ii. Business Name





5. Address Record

b. ECP and European Direct Debit (AM) Continued on next page




Validate / Account Status Verification with Account Owner Authentication / Pre-Note, (Continued): Response:


2. Product Record





Transaction Types and Requirements – POP/ARC Transactions

Validate Only - Validates this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file.

Online Request:


a. Action Code = LO

b. MOP = EC


2. Format Indicator


i. ECP Authorization Method = A or P

Response:



a. Action Code = LO

b. MOP = EC


2. Extension Record


i. Account Type

ii. ECP Authorization Method = A or P

iii. Check Serial Number (U.S. ECP only)

iv. Terminal City (POP transactions only)

v. Terminal State (POP transactions only)

vi. Image Reference Number

Response:





Transaction Types and Requirements – POP/ARC Transactions, (Continued)

Validate and Deposit this transaction. Batch Request:


a. Action Code = DO

b. MOP = EC

2. Extension Record


i. Account Type


iii. Check Serial Number





a. ECP and European Direct (KA)

4. Address Record


Response:





Transaction Types and Requirements – POP/ARC Transactions, (Continued)

Validate and Refund this transaction against an ACH eligibility file, Notification of Change (NOC) file, and ECP Internal Negative File. If the validation passes, issue a credit to this account. Batch Request:


a. Action Code = ER

b. MOP = EC

2. Extension Record


i. Account Type


iii. Check Serial Number





a. ECP and European Direct (KA)

4. Address Record


Response:





Transaction Types and Requirements –POP / ARC Transactions (Continued)

Validate / Account Status Verification this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM.

Online Request:


a. Action Code = W1

b. MOP = EC

c. Amount = greater than zero Note: Required for Early Warning System – Standard POS transactions

Response:



a. ECP Advanced Verification Reply (AV)


Batch Request:


a. Action Code = W1

b. MOP = EC


2. Extension Record


i. Account Type



Note: Required for Early Warning System – Standard POS transactions.



Transaction Types and Requirements –POP / ARC Transactions (Continued)

Validate / Account Status Verification, (Continued) Batch Response:

1. S" Record Output

2. Product Record





Transaction Types and Requirements – POP/ARC Transactions (Continued)

Validate / Account Status Verification with Account Owner Authentication this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM. Online Request:


a. Action Code = W3

b. MOP = EC




i. ECP Authorization Method = A or P

b. ECP Advanced Verification (AV01)


or

c. ECP Advanced Verification 2 (PAV002)

i. Business Name

Note: Send First Name and Last Name or Business Name.

d. ECP Advanced Verification (AV03)

i. Check Serial Number (U.S. ECP only)

Note: Required for Early Warning System – Standard POS transactions e. ECP Advanced Verification 4 - (AV04) (Optional)





Validate / Account Status Verification with Account Owner Authentication, (Continued):

Response: 1. Online Processing Return Format Record


a. ECP Advanced Verification Reply (AV)

Batch Request:


a. Action Code = W3

b. MOP = EC


2. Extension Record


i. Account Type



Note: Required for Early Warning System – Standard POS transactions




Validate / Account Status Verification with Account Owner Authentication, (Continued) Batch Request:

3. Product Records




i. Business Name




e. ECP Advanced Verification 5 - (PAV005) (Optional) Response:


2. Product Record




Transaction Types and Requirements –POP/ARC Transaction (Continued)

Validate / Account Status Verification / Deposit this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes, deposit the transaction. Batch Request:


a. Action Code = W4

b. MOP = EC

2. Extension Record


i. Account Type



iv. Terminal city (POP transaction only)

v. Terminal State (POP transaction only)

vi. Image Reference Number (POP transaction only



4. Address Record


Response:


2. Product Record






Validate / Account Status Verification with Account Owner Authentication / Deposit this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM .If the verification passes, deposit the transaction. Batch Request:


a. Action Code = W5

b. MOP = EC

2. Extension Record


i. Account Type





vi. Image Reference Number (POP transaction only)

3. Product Records



or


ii. Business Name




e. ECP Advanced Verification 5 - (PAV005) (Optional)





Validate / Account Status Verification with Account Owner Authentication / Deposit, (Continued): Batch Request:



5. Address Record


Response:


2. Product Record


Notes: Only returned if the merchant is properly enabled for the ECP Verification System.




Transaction Types and Requirements –POP/ARC Transactions (Continued)

Validate / Account Status Verification / Refund this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. If the validation passes, issue a credit to this account. Batch Request:


a. Action Code = W6

b. MOP = EC

2. Extension Record


i. Account Type




iv. Terminal City (POP transaction only)




i. ECP and European Direct Debit (KA)

4. Address Record

i. ECP and European Direct Debit (AM)

Response:







Validate / Account Status Verification with Account Owner Authentication / Refund this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM .If the verification passes issue a credit to this account. Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = W7 b. MOP = EC

2. Extension Record a. Electronic Check Processing (EEC001)

i. Account Type ii. ECP Authorization Method = A or P iii. Check Serial Number (U.S. ECP only)


iv. Terminal City (POP transaction only) v. Terminal State (POP transaction only) vi. Image Reference Number (POP transaction only)

3. Product Records a. ECP Advanced Verification - (PAV001)

i. First Name and Last Name or

b. ECP Advanced Verification - (PAV002) i. Business Name


c. ECP Advanced Verification 3 - (PAV003) (Optional) d. ECP Advanced Verification 4 - (PAV004) (Optional) e. ECP Advanced Verification 5 - (PAV005) (Optional)





Validate / Account Status Verification with Account Owner Authentication / Refund, (Continued): Batch Request:



5. Address Record


Response:


2. Product Record







Validate / Account Status Verification / Pre-Note this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes, send a pre-note to the customer’s bank. Batch Request:


a. Action Code = W8

b. MOP = EC

2. Extension Record


i. Account Type









4. Address Record


Response:


2. Product Record






Validate / Account Status Verification with Account Owner Authentication / Pre-Note this transaction against a Notification of Change (NOC) file, an ACH eligibility file, and an ECP internal negative file. If the validation passes, the Account Status Verification and Account Owner Authentication service is invoked using the Early Warning System’s National Shared DatabaseSM. If the verification passes send a pre-note to the customer’s bank. Batch Request:


a. Action Code = W9

b. MOP = EC

c. Amount = greater than zero


2. Extension Record


i. Account Type


iii. Check Serial Number (U.S. ECP only


iv. Terminal City (POP transaction only)



3. Product Records



or


i. Business Name

Note: Send First Name and Last Name (PAV001) or Business Name (PAV002) Continued on next page





Validate / Account Status Verification with Account Owner Authentication / Pre-Note, (Continued) Batch Request:



5. Address Record

b. ECP and European Direct Debit (AM)

Response:


2. Product Records







ECP Merchant User Guide Best Practice Guide Know Your Customer slide deck eCheck Supplemental Sample Kit


Electronic Check Processing / U.S. Dollar and Canadian Dollar



To Get Started



APPENDIX Y: ACCOUNT UPDATER



APPENDIX Z: RETAIL Introduction Merchant Services offers merchants the ability to process card present

transactions.

How It Works All transactions are authorized via online processing. All transactions are

settled via batch processing.


Credit Card Authorization with swipe data Online Request:


a. Action Code = AU

2. Format Indicator

a. Retail (RE) or Retail 3 (R3)

i. Format Indicator R3 must be sent when MOP = AX Response:

1. Online Processing Return Format Record Credit Card Authorization without swipe data Online Request:


a. Action Code = AU

2. Format Indicator

a. Bill To Address (AB) or Postal Code Only Address (AZ)

i. Postal Code is the minimum requirement to obtain the lowest possible interchange rate for manually keyed transactions

ii. Should be the accountholder’s postal code, otherwise some Issuers may decline the transaction

Response:




APPENDIX Z: RETAIL, (Continued)


Deposit Batch Request:

1. Detail Record (“S" Record Input)

a. Action Code = DP

2. Product Record

a. Retail (PRR001) (Optional)

Response:

1. “S” Record Output

Refund Batch Request:

1. Detail Record (“S" Record Input)

a. Action Code = RF

2. Product Record

a. Retail (PRR001) (Optional) Response:



Appendix L: Debit Processing Appendix G: Partial Authorizations


All credit cards/ U.S. and Canadian Dollars PIN-Based Debit/U.S. currency



To Get Started



APPENDIX AA: MASTERCARD IDENTIFICATION OF PRE AND FINAL AUTHORIZATIONS

Introduction MasterCard is mandating that authorizations in U.S, U.S Territories, Canada

Europe are identified as either a final authorization or a pre-authorization. This allows issuers to apply alternative processing by introducing a number of authorization improvements to achieve the following key objectives:

• Enable a more accurate and transparent management of the card account’s “open-to-buy”, in order to improve cardholder satisfaction and address regulatory concerns with the current situation;

• Redefine the issuer payment guarantee that is engaged when authorizing a transaction by introducing a maximum time limit in place of the currently unlimited duration and by defining it based on characteristics of the authorization or pre-authorization request; and

• Permit acquirers and issuers to identify and clearly distinguish a pre-authorization from a final authorization, thus giving them the option to treat them differently, to the ultimate benefit of their cardholders.

How It Works Pre-authorization

A pre-authorization is an authorization for an amount greater than zero, and meets one or both of the following two conditions:

1. Authorization is requested for an estimated amount.

2. Transaction might not be completed for reasons other than technical failure or lack of full issuer approval. For example, the transaction might not be completed when the cardholder is offered the choice to complete the transaction with another method of payment at a later time (such as, when checking out of a hotel or returning a rental car) or when the goods ordered by the cardholder might be later found to be out of stock. The risk of technical failures such as telecommunications failure or terminal failure should not be taken into account to determine if an authorization must be coded as a pre-authorization.



APPENDIX AA: MASTERCARD IDENTIFICATION OF PRE AND FINAL AUTHORIZATIONS, (Continued)


Pre-authorization, (Continued) MasterCard pre-authorizations are valid for 30 calendar days.

MasterCard and International Maestro pre-authorizations can be reversed.

The rules for International Maestro include:

• Pre-authorizations are only valid for seven days. • Pre-authorizations are only permitted for Automated Fuel Dispenser

(AFD) transactions and card-not-present (CNP) transactions • Estimated amounts are only permitted for AFD (MCC 5524)

transactions. • CNP pre-authorization amounts should equal the final authorization

amounts.

In Europe, MasterCard applies a service fee to a pre-authorization transaction when it is partially or fully approved.

In all other regions, if an approved pre-authorization is not reversed or settled within 30 calendar days, a non-compliance Processing Integrity fee will apply. Final Authorization

A final authorization is an authorization for an amount greater than zero and is the final transaction amount expected to be settled.

MasterCard and International Maestro final authorizations are valid for 7 calendar days.

The authorization should be settled or reversed within 7 calendar days.

The risk of technical failures such as telecommunications failure or terminal failure should not be taken into account to determine if an authorization must be coded as a final authorization.

MasterCard applies a Processing Integrity Fee for improperly coded authorizations when they do not meet specific conditions, including:

• Not settled or reversed within 7 calendar days • Cleared for a different currency or transaction amount than what was

authorized.

This fee is also applied to final authorizations that do not clear because of technical failures. However, this fee will not be applied when (because of technical failure or any other reasons) the number of final authorizations is lower than 1% of the total number of final authorizations of a given acquirer.



APPENDIX AA: MASTERCARD IDENTIFICATION OF PRE AND FINAL AUTHORIZATIONS, (Continued)


Default Set Up for the Merchant’s Transaction Division Default settings are entered into the Merchant Services processing system to manage the outcome of the authorization designation at the transaction division level. If the merchant’s transaction division is set to a default to either ‘Pre’ or ‘Final’ authorization, the default can be overridden at the transaction level for MasterCard and International Maestro.



APPENDIX AA: MASTERCARD IDENTIFICATION OF PRE AND FINAL AUTHORIZATIONS,

(Continued) Transaction Types and Requirements for Pre-authorizations

The following transaction requirements describe pre-authorizations for transactions. Online Request:


a. Method of Payment = IM or MC

b. Action Code = AU

2. Format indicator


i. Subtype Flag = P

Response:


Batch Request:


a. Action Code = AU

b. Method of Payment = IM or MC

2. Extension Record

a. International Maestro - Payment Action (EIM003), or

MasterCard – Payment Action (EMC003)

i. Subtype Flag = P

Response:





(Continued) Transaction Types and Requirements for Pre-authorizations, (Continued)

The following transaction requirements describe pre-authorization reversal transactions. Online Request:



b. Action Code = AR

2. Format indicator


i. Subtype Flag = P

Response:


Batch Request:


a. Action Code = AR


2. Extension Record



i. Subtype Flag = P

Response:





(Continued) Transaction Types and Requirements for Final Authorizations

The following transaction requirements describe final authorizations for transactions. Online Request:



b. Action Code = AU

2. Format indicator


i. Subtype Flag = F

Response:


Batch Request:


a. Action Code = AU


2. Extension Record



i. Subtype Flag = F

Response:





(Continued) Card Types / Supported Currencies

International Maestro and MasterCard / USD, CAD and International currencies



To Get Started



APPENDIX AB: ACCOUNT VERIFICATION

Introduction Account Verification transactions are used to verify accounts without financially impacting the accountholder’s open to buy. Address Verification Service and Card Security Value can be verified along with the account number. Issuers must be able to process Account Verification transactions and respond to all aspects of the transaction. To increase the utility and consistency of the verification response, ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit forward all Account Verification transactions to the Issuer when the Issuer is available and continue to respond to these requests when the Issuer is not available.

How It Works ChaseNet, International Maestro, MasterCard, MasterCard Canadian Domestic Restricted Debit, Visa, and Visa Canadian Domestic Restricted Debit currently process most Account Verification transactions on behalf of Issuers by checking the exception file and performing a check digit validation. Successful Account Verification transactions return Response Reason Code 104 (No Reason to Decline).



APPENDIX AB: ACCOUNT VERIFICATION, (Continued)


Verifies the account request. Online Request:


a. Action Code = VF

b. MOP = CR, CZ, IM, MC, MR, VI, or VR



a. Bill to Address (AB) or Postal Code Only Address (AZ) (Optional)

b. Fraud (FR) (Optional)

Response:


Batch Request:


a. Action Code = VF

b. MOP = CR, CZ, IM, MC, MR, VI, or VR


2. Product Record


3. Formatted Address Record (Optional)

a. Bill to Address (LA)

4. Address Record (Optional)


Response:




APPENDIX AB: ACCOUNT VERIFICATION, (Continued)


ChaseNet / U. S. Dollars

International Maestro, MasterCard, and Visa / All currencies





To Get Started



APPENDIX AC: FRAUD FILTERS

Introduction Fraud filters provide a way for a merchant to perform self-service fraud protection at both the domestic and international levels. Fraud filters contain specific card numbers, card prefixes, and issuing countries. Fraud filters are supported for the following MOPs and Action Codes for both Online and 120 Byte Batch:

Supported MOPs (Online and 120 Byte Batch)

Supported Action Codes (Online and 120 Byte Batch)

• American Express • ChaseNet • Discover • Discover Diners • ECP (Routing Number only) • Generic PINless Debit • International Maestro • MasterCard • MasterCard Canadian

Domestic Restricted Debit • Visa • Visa Canadian Domestic

Restricted Debit

• AU (Authorization) • DC (Conditional Deposit) • DO (Validate & Deposit) • ER (Validate & Refund) • LO (Validate only) • PA (Purchase Authorization) • PR (Purchase Authorization

Reversal) • RA (Refund Authorization) • RF (Refund) • VD (Validate, Verify & Deposit) • VF (Verification) • VO (Validate & Verify)

They are also supported for the following 96 Byte Batch MOPs and Action Codes:

Supported MOPs (96 Byte Batch)

Supported Action Codes (96 Byte Batch)

• American Express • ChaseNet • Discover • Discover Diners • ECP (Routing Number only) • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit

• A (Authorization) • B (Conditional Deposit) • E (Authorization Reversal) • F (Verification) • G (Validate & Verify) • H (Validate & Deposit) • I (Validate, Verify & Deposit) • N (Validate & Refund) • R (Refund) • V (Validate only)

There are three types of fraud filters that can be used: • Card Number Prefix • Card Number • Issuing Country The following tables identify the supported MOP/Action Code combinations for each filter.



APPENDIX AC: FRAUD FILTERS, (Continued)

Card Number Prefix

The ability to reject transactions based on cards with a specific card number prefix.



• American Express • ChaseNet • Discover • Discover Diners • Generic PINless Debit • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit

• AU (Authorization) • DC (Conditional Deposit) • PA (Purchase

Authorization) • PR (Purchase

Authorization Reversal) • RA (Refund Authorization) • RF (Refund) • VF (Verification)



• American Express • ChaseNet • Discover • Discover Diners • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit

• A (Authorization) • B (Conditional Deposit) • E (Authorization Reversal) • F (Verification) • R (Refund)




Card Number The ability to reject transactions based on a specific card number.

Supported MOPs

(Online and 120 Byte Batch) Supported Action Codes

(Online and 120 Byte Batch) • American Express • ChaseNet • Discover • Discover Diners • Generic PINless Debit • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit






• American Express • ChaseNet • Discover • Discover Diners • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit





Issuing Country

The ability to reject transactions based on a card issued in a particular country.



• ChaseNet • Discover • Discover Diners • International Maestro • MasterCard • MasterCard Canadian


Restricted Debit






• ChaseNet • Discover • Discover Diners • International Maestro • MasterCard • MasterCard Canadian

Domestic Restricted Debit

• Visa • Visa Canadian Domestic

Restricted Debit


Card Issuing Country Status Definitions:

o Acceptable – Transaction is authorized. o Suspect – Transaction is authorized and indicates that the

transaction used a card issued in a suspect country. o Blocked – Transaction is rejected and not sent for authorization.

Note: This fraud filter applies to any MOP where the card association has provided issuing country information.





A merchant must be enabled to use fraud filters. Contact your Merchant Services Representative. Consult the Fraud Filter Tool User Guide for information on how to manage the filters.

How It Works If a merchant is enabled for any of the fraud filters, the order of precedence is as follows:

• Card Number Prefix • Card Number • Issuing Country

For a transaction where the card number prefix is filtered, the transaction rejects with Response Reason Code 269 (Card Prefix on Fraud Filter List).

For a transaction where the card number is filtered, the transaction rejects with Response Reason Code 270 (Card Number on Fraud Filter List).

For a transaction where the Issuing country is filtered, the transaction rejects with Response Reason Code 271 (Country on Fraud Filter List).

If a merchant attempts to process a transaction for an issuing country that is on their associated Issuing Country Fraud Filter and that has successfully passed the prior edits, either the Card Issuing Country Status Reply Format Indicator (CS) or the Product Record: Card Issuing Country Status (PCS001) returns one of the following values:

• A – Returned if the country is found to be Acceptable. • B – Returned if the country is found to be Blocked. • S – Returned if the country is found to be Suspect.





Fraud Filter Tool User Guide


Most card types / All currencies





APPENDIX AD: SHOP WITH POINTS

Introduction Shop with Points provides customers of merchant partners with the ability to pay with Chase Reward Points for purchases made on the merchant’s website and retail locations. Shop with Points includes the ability for the customer to pay a portion of the purchase using Chase Reward Points and the balance with another method of payment.

How It Works A merchant’s customer must provide an account that is associated with the

Issuer’s rewards program. The merchant verifies the customer’s account using a Shop with Points BIN file provided by Chase Loyalty Services. Once the account is verified through the BIN file, the merchant needs to perform a Balance Inquiry/Account Profile to determine the customer’s current eligibility and enrollment status. If a customer is enrolled, then the merchant can proceed to attempt a Shop with Points authorization. If the customer is eligible and not enrolled, the merchant may solicit the customer to register in the rewards program. Once registered, the merchant may attempt a Shop with Points authorization. Rewards are debited from the customer’s account at the time of authorization. The authorization duration is 30 days. If the authorization expires, the rewards are credited back to the customer’s account. Rewards represent a dollar value that a merchant’s customers can redeem for purchases. The actual record of the rewards balance on the account is maintained by the Issuer.



APPENDIX AD: SHOP WITH POINTS, (Continued)


Current Balance Inquiry/Account Profile verifies customer’s eligibility and rewards points profile. This action should be performed prior to authorization and register actions to retrieve information required for those actions. Online Request:


a. Action Code = BI

b. Amount is ignored

c. Method of Payment = C9

Response:


a. Authorization / Verification Code is blank


a. Shop with Points (SP)





Register the card account for a Shop with Points program. Online

Request:


a. Action Code = ET



2. Format Indicator


Response:









Unregister the card account with a Shop with Points program. Online Request:


a. Action Code = UT



Response:


a. Authorization / Verification Code is blank.





Authorization verifies customer’s available rewards points and if they are available, debits the customer’s account. Online Request:


a. Action Code = AU

b. Method of Payment = C9



i. Product Code

ii. Conversion Rate

iii. Shop with Points Trace Number (Optional)

b. Split Tender (ST) (Optional)

Response:



a. Shop with Points Information (SI)

i. Shop with Points Trace Number (echoed back from Order Information 6 (O6) Format Indicator)

Note: Returned only when Response Reason Code = 100 (Approved).





Authorization Reversal reverses the previously approved authorization. Online Request:


a. Action Code = AR

b. Method of Payment = C9



i. Product Code

ii. Conversion Rate

iii. Shop with Points Trace Number (Optional)


i. Response Date = approved, original, authorized date ii. Authorization Code = approved, original, authorization

code c. Split Tender (ST) (Optional)

Response:



a. Shop with Points Information (SI)

i. Shop with Points Trace Number (echoed back from Order Information 6 (O6) Format Indicator)

Note: Returned only when Response Reason Code = 100 (Approved).





Healthcheck returns a status for the Shop with Points program. Online Request:


a. Action Code = HC



d. Account Number (assigned by Issuer)

Response:









Deposit funds the merchant for the previously approved authorization. Batch Request:


a. Action Code = DP

b. Response Date

c. Authorization/Verification Code

d. Split Tender Indicator (Optional)

Note: Recommended when MOP = C9, MC, VI to tie split payments together.

2. Product Record

a. Product Record: Shop with Points (PSP001)

i. Conversion Rate

ii. Product Code (Optional)

Response:






Refund adds amount to the balance of a Shop with Points account. Batch Request:


a. Action Code = RF

b. Split Tender Indicator (Optional)

2. Product Record

a. Product Record: Shop with Points (PSP001)

i. Conversion Rate

Response:






Shop with Points / U.S. Dollars



To Get Started Contact your Merchant Services Representative to request a new project be

initiated.


APPENDIX AE: SAFETECH FRAUD TOOLS Introduction Safetech Fraud Tools is a solution which enables a merchant to determine if

an accountholder is a serious fraud risk. The Safetech fraud scoring is based on various scoring criteria.

The Fraud Score is a numerical representation of the relative risk of each and every transaction that is screened and is composed of over 200 different variables. This information can be used to enhance current risk programs or can be used by a merchant to customize their approach to risk management.

The merchant is solely responsible for the decision to proceed with a transaction should the system return a high fraud score. Merchant Services simply provides the information to the merchant to use as they see fit.

How It Works When an accountholder uses their account to make a purchase, the

merchant can request Safetech fraud scoring be performed on the transaction. A merchant indicates this request by sending a Fraud Scoring Format Indicator (KT01 or KT02) or Product Records: Fraud Scoring Input Data 1 and 2 (PKTI01 and PKTI02) to Merchant Services. Regardless of whether the transaction is approved or declined, the transaction is sent through the Safetech fraud scoring system.

Merchant Services does not reject a transaction based on the Safetech fraud scoring data. That data is passed to the Safetech fraud scoring system for evaluation. For further details on this product, refer to the Safetech Fraud Tools User Guide.

Fraud Analysis Only

Safetech allows a merchant to send a fraud analysis only transaction. When a merchant sends Action Code = FA, only fraud analysis is performed on the transaction. The transaction is not sent to the Issuer.

When Action Code = FA, the transaction must contain a Fraud Scoring Format Indicator (KT01 or KT02) or Product Record: Fraud Scoring Input Data 1 (PKTI01) or the transaction rejects with Response Reason Code 227 (Missing Companion Data).

This action code can be used to obtain RIS information on Methods of Payment not processed with Merchant Services.

• The Transaction Division must be set up with MOP = SV. • See the Transaction Types and Requirements section for details.

Merchants are required to test Action Code = FA.



APPENDIX AE: SAFETECH FRAUD TOOLS, (Continued)

Supported MOPs and Corresponding Action Codes - Online

Safetech fraud scoring is supported for many Online MOPs and Action Code combinations. The following table shows the combinations:

MOP Code MOP Description Action Code AE ACCEL PIN-Based Debit PA AF AFFN PIN-Based Debit PA AP ACCEL PINless Debit FA, PA, RA AT ATH PIN-Based Debit PA AX American Express AU, FA BL Bill Me Later AU, FA BP Bill Me Later Private Label AU, FA CR ChaseNet - Signature

Debit/Prepaid AU, BI, FA, VF

CU CU24 PIN-Based Debit PA CZ ChaseNet - Credit AU, BI, FA, VF DD Discover Diners AU, BI, FA DE Generic PIN-Based Debit FA, PA DI Discover AU, BI, FA DP Generic PINless Debit FA, PA, RA EC Electronic Check FA, LO, VO ED European Direct Debit FA, LO IL Interlink PIN-Based Debit PA IM International Maestro AU, FA JC JCB AU, FA JN Jeanie PIN-Based Debit PA MC MasterCard AU, BI, FA, VF MR MasterCard Canadian

Restricted Debit AU, BI, FA, VF

MP MoneyPak BI, FA, PA, RA MT Maestro PIN-Based Debit PA NP NYCE PINless Debit FA, PA, RA NY NYCE PIN-Based Debit FA, PA




Supported MOPs and Corresponding Action Codes - Online, (Continued)

MOP Code MOP Description Action Code PP Pulse PINless Debit PA, RA PS Pulse PIN-Based Debit PA PY PayPal AU, ED, FA SP Star PINless Debit FA, PA, RA

SR Star PIN-Based Debit PA

SV Gift Card AU, BI, FA

SZ Shazam PIN-Based Debit PA

VI Visa AU, BI, FA, VF

VR Visa Canadian Restricted Debit

AU, BI, FA, VF

Supported MOPs and Corresponding Action Codes – Batch

Safetech fraud scoring is supported for many Batch MOPs and Action Code combinations. The following table shows the combinations:

MOP Code MOP Description Action Code

AP ACCEL PINless Debit PA, FA, RA AT ATH PIN-Based Debit PA AX American Express AU, FA BL Bill Me Later AU, FA BP Bill Me Later Private Label AU, FA CR ChaseNet - Signature

Debit/Prepaid AU, BI, FA, VF

CZ ChaseNet - Credit AU, BI, FA, VF

DD Discover Diners AU, BI, FA DI Discover AU, BI, FA DP Generic PINless Debit FA, PA, RA EC Electronic Check FA, LO, NC,

ND, VO, VP ED European Direct Debit FA, LO IM International Maestro AU, FA




Supported MOPs and Corresponding Action Codes - Batch, (Continued)


JC JCB AU, FA MC MasterCard AU, BI, FA,

VF MR MasterCard Canadian

Restricted Debit AU, BI, FA, VF

MP MoneyPak BI, FA, PA NP NYCE PINless Debit FA, PA, RA

PP Pulse PINless Debit FA, PA, RA

PY PayPal AU, FA

SP Star PINless Debit FA, PA, RA

SV Gift Card AU, BI, FA

VI Visa AU, BI, FA, VF

VR Visa Canadian Restricted Debit

AU, BI, FA, VF




Fraud Status Codes

A fraud status code is returned for every fraud inquiry when the transaction is approved or declined. The first character of the Fraud Status Code can be used to identify the type of status. The following chart lists the characters and their description.

First Character Type of Status

Y Post authorization check X Pre authorization check A Successful fraud score T No fraud score, internal error K Fraud system error

The following chart lists all currently defined Merchant Services fraud status codes. Many of these codes are never returned in the output.

Fraud Status Code

Description

Y001 Authorization timed out. RIS inquiry not attempted.

X001 Merchant not enabled for Safetech fraud scoring

X002 MOP not supported for Safetech fraud scoring

X003 Action Code not supported for Safetech fraud scoring

X004 Transaction Type not supported for Safetech fraud scoring

X005 Safetech Merchant ID not sent on transaction

X006 Safetech Merchant ID supplied does not match the division setup on file

X007 PayPal transaction was not scored due to a missing Payer ID.

X008 Invalid Shopping Cart Data. RIS Inquiry Not Attempted

X009 Invalid User-Defined Field Data. RIS Inquiry Not Attempted




Fraud Status Codes, (Continued)

Fraud Status Code

Description

A000 Fraud score successful

T998 Internal server error where the fraud system is unreachable

T999 Fraud system unreachable

K201 The version number is missing. Internal to Merchant Services.

K202 The mode is missing.

K203 The Merchant ID is missing.

K204 The Session ID is missing

K205 The RIS Transaction ID is missing.

K211 The Currency Code is missing.

K212 The Total Authorization Amount is missing.

K221 The Email Address is missing.

K222 The Phone Number is missing.

K223 The Website ID is missing.

K231 The Payment Type is missing.

K232 A Payment Type of Card is missing.

K233 The Payment Type of MICR is missing. MICR is the Magnetic Ink Character Recognition (MICR) line on a check.

K234 The PayPal PayerID field is missing.

K235 The Payment Token (Amount) is missing

K241 The customer IP Address is missing.

K251 The merchant acknowledgement flag is missing.

K261 The POST is missing

K271 The Product Type code is missing.

K272 The Product Item code is missing.





Fraud Status Code

Description

K273 The Product Description is missing.

K274 The Product Quantity is missing.

K275 The Product Price is missing.

K301 The Version Number is invalid.

K302 The Mode is invalid.

K303 The merchant ID is invalid.

K304 The Session ID is invalid.

K305 The RIS Transaction ID is invalid.

K311 The currency code is invalid.

K312 The total authorization amount is invalid.

K321 The customer’s email address is invalid.

K322 The customer’s phone number is invalid.

K323 The Website ID is invalid.

K324 The format of the RIS response is invalid.

K331 The transaction type is invalid.

K332 The card used as payment is invalid.

K333 The Payment Type of MICR is invalid. MICR is the Magnetic Ink Character Recognition (MICR) line on a check.

K334 The PayPal PayerID field is invalid.

K335 The Google checkout account ID is invalid.

K336 The Bill Me Later account number is invalid.

K341 The customer IP address is invalid.

K351 The merchant acknowledgement flag is invalid.





Fraud Status Code

Description

K362 The shopping cart data is invalid.

K371 The Product Type code is invalid.

K372 The Product Item code is invalid.

K373 The Product Description is invalid.

K374 The Product Quantity is invalid.

K375 The Product Price is invalid.

K399 The label either doesn’t exist in the AWC or was associated with the wrong data type.

K401 Extra data was included in the transaction.

K402 The payment types were mis-matched.

K403 A customer phone number was sent in, but was unnecessary.

K404 A Payment Token was sent in that was unnecessary.

K501 A Scoring request was sent in that was not authorized.

K502 A merchant ID was sent in that was not authorized.

K503 An IP address was sent in that was not authorized.

K504 A time-out of the fraud detection service occurred.

K601 A system error occurred.

K602 Submission of data that appears to be a security breach. This security breach may come from a known bad IP, email address, etc.

K701 A header is missing from the transaction.





Fraud Scoring determines the risk factor of a specific accountholder based on various criteria. Online Request:


a. Action Code = AU, BI, ED, FA, LO, PA, RA, VF, VO


a. Customer ANI (AA) (Optional – Recommended for phone orders)

i. Customer ANI (Automatic Number Identification)

b. Bill to Address (AB) (Optional – Recommended for all orders)

c. IP Address (AI) (Optional – Recommended for web orders)

i. Customer IP Address

d. Email Address (AL) (Optional – Recommended for all orders)

i. Email Address

e. Customer Browser (AR) (Optional – Recommended for web orders)

f. Ship to Address (AS) (Optional – Recommended for all orders)

g. Fraud Scoring 1 or 2 (KT01 or KT02)

h. User Defined and Shopping Cart (KTT1) (Optional)

i. Order Information (OI) (Optional – Recommended for all orders)

i. Shipping Method

j. Personal Information 2 (P2) (Required when MOP = PY and Action Code = AU or FA)

i. Payer ID

Response:



a. Fraud Scoring 1 or 2 (KT01 or KT02)

b. Rules Triggered (KR) (Optional)





Fraud Scoring, (Continued) Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = AU, BI, FA, LO, NC, ND, PA, RA, VF, VO, VP


i. Payer ID (Required when MOP = PY) 3. Information Record

a. Order Information (IOI) (Optional – Recommended for all orders)

i. Shipping Method 4. Product Records

a. Fraud Scoring Input Data 1 (PKTI01) b. Fraud Scoring Input Data 2 (PKTI02) (Optional) c. User Defined and Shopping Cart (PKTT01-20) (Optional)

5. Formatted Address Records a. Bill to Name (LA) (Optional – Recommended for all orders) b. Ship to Address (HA) (Optional – Recommended for all

orders) 6. Address Records

a. Bill to Address (AB) b. IP Address (AI)

i. Customer IP Address – Recommended for all web orders

c. Email Address (AL) (Optional – Recommended for all orders) i. Email Address

d. Customer ANI (AN) (Optional – Recommended for web orders)

i. Customer ANI (Automatic Number Identification) e. Customer Browser Name (AR) (Optional – Recommended for

all web orders) f. Ship to Address (AS)





Fraud Scoring, (Continued) Batch, (Continued) Response:


2. Product Records

a. Fraud Scoring Output Data 1 (PKTO01)

b. Fraud Scoring Output Data 2 (PKTO02)

c. Fraud Scoring Output Data 3 (PKTO03)

d. Rules Triggered (PKR001) (Optional)





Fraud Scoring for non-processed Methods of Payment. Online Request:

1. Online Processing Detail Record a. MOP = SV b. Account Number = all zeros c. Action Code = FA

2. Format Indicators a. Customer ANI (AA) (Optional – Recommended for phone

orders) i. Customer ANI (Automatic Number Identification)

b. Bill to Address (AB) (Optional – Recommended for all orders) c. IP Address (AI) (Optional – Recommended for web orders)

i. Customer IP Address d. Email Address (AL) (Optional – Recommended for all orders)

i. Email Address e. Customer Browser (AR) (Optional – Recommended for web

orders) f. Ship to Address (AS) (Optional – Recommended for all

orders) g. Fraud Scoring 1 or 2 (KT01 or KT02) h. User Defined and Shopping Cart (KTT1) (Optional) i. Order Information (OI) (Optional – Recommended for all

orders) i. Shipping Method

j. Personal Information 2 (P2) (Required when MOP = PY and Action Code = AU or FA)

i. Payer ID Response:


a. Fraud Scoring 1 or 2 (KT01 or KT02) b. Rules Triggered (KR) (Optional)





Fraud Scoring for non-processed Methods of Payment, (Continued) Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = FA b. MOP = SV


i. Payer ID (Required when MOP = PY) 3. Information Record

a. Order Information (IOI) (Optional – Recommended for all orders)

i. Shipping Method 4. Product Records

a. Fraud Scoring Input Data 1 (PKTI01) b. Fraud Scoring Input Data 2 (PKTI02) (Optional) c. User Defined and Shopping Cart (PKTT01-20) (Optional)

5. Formatted Address Records a. Bill to Address (LA) (Optional – Recommended for all orders) b. Ship to Address (HA) (Optional – Recommended for all

orders) 6. Address Records

a. Bill to Address (AB) b. IP Address (AI)

i. Customer IP Address – Recommended for all web orders

c. Email Address (AL) (Optional – Recommended for all orders) i. Email Address

d. Customer ANI (AN) (Optional – Recommended for web orders)

i. Customer ANI (Automatic Number Identification) e. Customer Browser Name (AR) (Optional – Recommended for

all web orders) f. Ship to Address (AS)





Fraud Scoring for non-processed Methods of Payment, (Continued) Batch, (Continued) Response:


2. Product Records

a. Fraud Scoring Output Data 1 (PKTO01)

b. Fraud Scoring Output Data 2 (PKTO02)

c. Fraud Scoring Output Data 3 (PKTO03)

d. Rules Triggered (PKR001) (Optional)





Safetech Fraud Tools User Guide

Kaptcha Data Collector Reference Guide

Safetech Event Notification Guide


Most Card Types / All Currencies



To Get Started

Contact your Merchant Services Representative


APPENDIX AF: THIRD PARTY VENDOR AUTHORIZATION LOGS AND DEPOSITS – MERCHANT SERVICES PLATFORMS

This product is not supported in Online Processing Format Specification


APPENDIX AG: VOYAGER



APPENDIX AH: WRIGHT EXPRESS (WEX)



APPENDIX AI: LODGING AND VEHICLE RENTAL



APPENDIX AJ: CARD TYPE INDICATORS Introduction Card Type Indicators (CTI), also known as Enhanced Authorization

Information, define what type of card is being used by the consumer. The CTI can be provided in the transaction response for the following Action Codes:

• AU – Authorization • BI – Balance Inquiries • DC – Conditional Deposits (Batch Only) • VF – Verification

When JCB is referenced in this appendix, it only applies to U.S. merchants processing USD currency. These transactions are sent to Discover for processing.

How It Works When a merchant receives a debit or credit card for payment, they can

request to see CTI information on the transaction response.

A merchant makes this request by sending a Card Type Indicator Format Indicator (CT Version 01 or 02) or Product Record: Card Type Indicator Input Data (PCTI Version 01 or 02) to Merchant Services. Merchant Services then returns either a Card Type Indicator Reply Format Indicator (CT01 or CT02) or Product Record: Card Type Indicator Output Data (PCTO01 or PCTO02) to the merchant.

Only approved or declined transactions receive a card type indicator response.

If a value of "X" (Not applicable/unknown) is returned, this indicates the Card Brands did not provide specific card type information.



APPENDIX AJ: CARD TYPE INDICATOR, (Continued)

Use Cases The following examples of use cases explain the different card types that can be returned and the possible benefits of receiving the card type indicator information.

Card Type Indicator

Description Supported MOPs

Country Code/ Country of Issuance

Assists merchants in determining if a card is issued domestically or internationally.

CR, CZ, DD, DI, IM, JC, MC, MR, VI, VR

Durbin Allows the merchant to define whether the card Issuer’s card range is regulated or not from provisions within the Durbin Amendment.

A card Issuer’s card range would be regulated if the Issuer held more than $10 billion in assets. A regulated Issuer would be subject to the price caps and interchange rules as defined in the Durbin Amendment.

CR, CZ, DD, DI, JC, MC, MR, VI, VR

Commercial Card

Assists merchants in defining a card as a commercial card. This enables the merchant to send Level 2 transaction data.

CR, CZ, MC, MR, VI, VR

Prepaid Card

Allows merchants to determine when gift cards or prepaid cards are presented for use when establishing a new recurring, installment, or deferred billing relationship.


Payroll Card

Allows the merchant to determine if the card is a payroll card and identify the timing of settlement transactions.

CR, CZ, DD, DI, JC, VI, VR

Healthcare Card

Allows the merchant to determine if the card is a healthcare card.





Use Cases, (Continued)

Card Type Indicator

Description Supported MOPs

Affluent Category

Enables merchants to market high-end items to those customers with higher credit limits. It also enables merchants to understand what kind of cards their high-end customers are using. Card types that could be returned as Affluent include:

• Discover Premium • Discover Premium Plus • Visa Infinite • Visa Platinum • Visa Signature • ChaseNet Infinite • ChaseNet Platinum • ChaseNet Signature • MasterCard World • MasterCard World Elite


Signature Debit

Allows merchants to determine if this is a signature debit card, enabling merchants to alter the transaction behavior. For example, a merchant may not want to reauthorize a transaction and/or perform reversals promptly.

CR, IM, MC, MR, VI, VR

PINless Debit

Allows the merchant to designate a card as a PINless debit card for future transactions.

MC, MR, VI, VR

Level 3 InterchangeEligible

Allows the merchant to define a card as being Level 3 interchange eligible. This enables the merchant to send Level 3 transaction data to qualify for the best possible interchange rate at the time of deposit.






Card Type Indicator allows for the return of Card Type Indicator information on a transaction. Online Request:

1. Online Processing Detail Record a. Action Code = AU, BI, VF b. MOPS = CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR

2. Format Indicator a. Card Type Indicator (CT)

i. Version 01 or 02 Response:


a. Card Type Indicator (CT01) or b. Card Type Indicator (CT02) Note: Only returned for approvals and declines, not rejects.

Batch Request:

1. Detail Record ("S" Record Input) a. Action Code = AU, BI, DC, VF b. MOPS = CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR

2. Product Record a. Card Type Indicator Input Data (PCTI)

i. Version 01 or 02 Response:


a. Card Type Indicator Output Data (PCTO01) or b. Card Type Indicator Output Data PCTO02) Note: Only returned for approvals and declines, not rejects.





International Maestro, MasterCard, Visa / All Currencies

Discover and Discover Diners / U.S. Dollars and Canadian Dollars


JCB (U.S. Merchants) / U.S. Dollars

MasterCard Canadian Domestic Restricted Debit \ Canadian Dollars




To Get Started



APPENDIX AK: AIRLINES



APPENDIX AL: CHASENET Introduction ChaseNet is a proprietary payment platform for select JPMorgan Chase-

issued, Visa branded credit and signature and PIN-Based debit cards.

How It Works Participating Global merchants may choose to direct all eligible JPMorgan Chase Visa Signature Debit and Credit cards to ChaseNet in lieu of sending them to Visa for processing. ChaseNet supports all authorization, refund and deposit transactions for eligible payment cards. There are two ways to utilize the ChaseNet product. BIN File Management Merchants receive the ChaseNet BIN File to manage the BIN’s for these methods of payment. The specific MOP and MOP-associated records are sent with the transaction. MOP Reassignment MOP reassignment is enabled by using a Transaction Division flag. If the flag is enabled and the Transaction Division supports ChaseNet MOPs, MOP= VI can be sent on the transaction, and if the account number is an eligible ChaseNet BIN, the transaction is sent to ChaseNet. The ChaseNet MOP is returned in the reply record. The ChaseNet MOP should be sent in all subsequent transactions. If the flag is enabled and the Transaction Division supports ChaseNet MOPs, the following chart lists the MOPs and Extension Records that can be sent and received.

Submitted MOP

Submitted Extension Record

Returned MOP

Returned Extension Record

VI EVI001 / EVI002 / EVI003 CZ EVI001 / EVI002 / EVI003

VI EVI001 / EVI002 / EVI003 CR EVI001 / EVI002 / EVI003

CZ EVI001 / EVI002 / EVI003 CZ EVI001 / EVI002 / EVI003

CR EVI001 / EVI002 / EVI003 CR EVI001 / EVI002 / EVI003

CZ ECZ001 / ECZ002 / ECZ003 CZ ECZ001 / ECZ002 / ECZ003

CR ECR001 / ECR002 / ECR003 CR ECR001 / ECR002 / ECR003



APPENDIX AL: CHASENET (Continued) How It Works – PIN-Based Debit

A ChaseNet PIN-Based Debit transaction occurs when the card is swiped at the point of sale (POS) and the accountholder enters their Personal Identification Number (PIN). The PIN pad encrypts the PIN before it is sent for processing. See Appendix L: Debit Processing for additional information.

Certification All new certifications must validate the ability to handle all current ChaseNet method of payments. Please speak with your Merchant Services Representative to discuss using test divisions.


Account Updater Delimited File

ChaseNet BIN Range File Delimited Format

Appendix U: Test Systems





To Get Started



APPENDIX AM: CONSUMER DIGITAL PAYMENT TOKEN Introduction Issuer consortiums and payment brands worked together to develop and set

industry standards for Consumer Digital Payment Token (CDPT) transaction security. A CDPT is a surrogate value that resides in digital wallet applications and replaces the cardholder account number in transaction processing. American Express, Discover, JCB, MasterCard, ChaseNet, and Visa have made processing changes in support of the “Payment Token Standard”. These changes allow acquirer, merchant, and issuer CDPT implementations that provide enhanced security for cardholder Primary Account Number (PAN). Changes have been made to support accepting, recognizing, and processing CDPT based transactions.

How It Works CDPT is supported in both Near Field Communication/Contactless transactions

as well as Mobile In-application/Ecommerce transactions. These transactions consist of the CDPT as the account number and a dynamic cryptogram (a key that provides additional security).

Safetech Tokenization A Safetech Token can be created with a Consumer Digital Payment Token (CDPT) transaction. The financial transaction is attempted with the DPAN; and a Safetech Token may be returned in the response.

Initial and subsequent transactions submitted with a Safetech Token created from a CDPT transaction must adhere to the same transaction formatting rules as standard CDPT transactions. (i.e., submit all applicable cryptogram data, extension records and product records for CDPT support).



APPENDIX AM: CONSUMER DIGITAL PAYMENT TOKEN, (Continued)


American Express and JCB For the original authorization the DPAN value must be sent in the Account Number field and the Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

The cryptogram is provided to the merchant in one of two sizes:


• 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format For 28-byte Base 64 or 20-byte binary (hexadecimal ASCII character) format. Merchant must:

• Submit the value in the American Express Verification Value (AEVV) (Block A) field.

• Blank fill the Transaction ID (XID) (Block B) field.

For a 56-byte Base 64 or a 40-byte (hexadecimal ASCII character) format. Merchant must:

• Split the value into two equal blocks of data. • Submit the first block of data in the American Express Verification

Value (AEVV) (Block A) field. • Submit the second block of data in the Transaction ID (XID) (Block B)

field. Continued on next page




American Express and JCB, (Continued) For subsequent authorizations (i.e., split/delayed shipments), merchants must send the following static cryptogram in the American Express Verification Value (AEVV) (Block A) field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction ID (XID) (Block B) field must be blank or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For recurring transactions conducted with a CDPT, merchants must send the following static cryptogram in the American Express Verification Value (AEVV) (Block A) field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction ID (XID) (Block B) field must be blank or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). Note: JCB is for Canadian merchants only. Transactions are processed on the American Express network and use the same fields as American Express Discover For original authorizations, the CDPT value should be sent in the Account Number field. The cryptogram should be sent in the Cardholder Authentication Verification Value (CAVV) field. The Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For subsequent authorizations (i.e., split/delayed shipments), merchants must send the following static cryptogram in the CAVV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).





For recurring transactions conducted with a CDPT, merchants must send the following static cryptogram in the CAVV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). MasterCard For original authorizations, the CDPT value should be sent in the Account Number field. The cryptogram should be sent in the Accountholder Authentication Value (AAV) field. The Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For subsequent authorizations (i.e., split/delayed shipments), merchants must send the following static cryptogram in the AAV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “5” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For recurring transactions conducted with a CDPT, merchants must send the following static cryptogram in the AAV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

Magnetic Secure Transmission (MST) for Mobile Devices The mobile device transmits a mag stripe readable signal to the POS terminal, rather than using NFC. A merchant’s POS terminal that can read mag stripes, but does not support NFC, can accept this transaction. Mag stripe data is included in the transaction but a cryptogram is not. Transaction Type should equal R.





MasterCard Dynamic Token Verification Code (DTVC) Dynamic Token Verification Code (DTVC) is a simplified cryptogram for use with MasterCard Token Service based e-commerce transactions. This simplified cryptogram for token transactions is populated in the field used for the CVV2 value in PAN-based transactions, simplifying the process to support token-based e-commerce transactions.

For original authorizations and subsequent authorizations (not including recurring), the DTVC value should be sent in the Card Security Value field. The Card Security Presence field should be populated with a “1”. For recurring transactions conducted with a DTVC initially, merchants must send the following static cryptogram in the AAV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For token based transactions that are authenticated with MasterCard SecureCode/3-D Secure, the DTVC value should be sent in the Card Security Value field in conjunction with the AAV field.





ChaseNet and Visa For original authorizations, the CDPT value should be sent in the Account Number field. The cryptogram should be sent in the Cardholder Authentication Verification Value (CAVV) field. The Transaction Type field must be populated with “5” or “7” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For subsequent authorizations (i.e., split/delayed shipments), merchants must retain the original cryptogram and send it in the CAVV field. The Transaction Type field must be populated with 5 (non-HCE), or 7 (HCE) or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For recurring transactions conducted with a CDPT, merchants must send the following static cryptogram in the CAAV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). For all transactions within both the Cardholder Initiated Transaction (CIT) and Merchant Initiated Transaction (MIT) Frameworks, the cryptogram value is “optional”. For CIT transactions, if a cryptogram value is provided, it is subject to the existing formatting edits (e.g., Base 64 encoding) and is sent to Visa in the Authorization Request. For CIT transactions involving an authentication yielding a dynamic cryptogram, it is the responsibility of the Merchant to send the cryptogram in their Authorization Request to Chase. If the appropriate authentication data is not provided, it could result in a declined transaction from Visa or the Issuer. For MIT transactions, if a cryptogram value is provided, it is not sent to Visa in the Authorization Request.




How It Works, (Continued) Magnetic Secure Transmission (MST) for Mobile Devices

The mobile device transmits a mag stripe readable signal to the POS terminal, rather than using NFC. A merchant’s POS terminal that can read mag stripes, but does not support NFC, can accept this transaction. Mag stripe data is included in the transaction but a cryptogram is not. Transaction Type should equal R.

Host Card Emulation (HCE) for Mobile Devices The mobile device retrieves the credentials from the cloud to create the payment transaction. A DPAN and a cryptogram are included in the transaction. Transaction Type should equal 2 or 7.





ChaseNet and Visa , (Continued) Dynamic Token Verification Value (DTVV)

Dynamic Token Verification Value (DTVV) is a simplified cryptogram for use with Visa Token Service based e-commerce transactions. This simplified cryptogram for token transactions is populated in the field used for the CVV2 value in PAN-based transactions, simplifying the process to support token-based e-commerce transactions.

For original authorizations and subsequent authorizations (not including recurring), the DTVV value should be sent in the Card Security Value field. The Card Security Presence field should be populated with a “1”. For recurring transactions conducted with a DTVV initially, merchants must send the following static cryptogram in the CAVV field: “SUBSEQUENT000000000000000000” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with “2” or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).

For token based transactions that are authenticated with Verified by Visa/3-D Secure, the DTVV value should be sent in the Card Security Value field in conjunction with the CAVV field.




Transaction Types and Requirements – American Express and JCB

Original Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = AX or JC



a. American Express Authentication (XA)

Or

JCB Authentication (JA)

b. Digital PAN (DN) (Optional)

Response:


2. Format Indicator

a. Digital PAN (DN)




Transaction Types and Requirements – American Express and JCB

Original Authorization, (Continued) Batch Request:


a. Action Code = AU

b. MOP = AX or JC


2. Extension Record

a. American Express Authentication (EAX004)

or


3. Product Record

a. Digital PAN (PDN001) (Optional)

Response:


2. Product Record

a. Digital PAN (PDN001)



Transaction Types and Requirements – American Express and JCB, (Continued)

Subsequent Authorization (i.e., split/delayed shipments) verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = AX or JC




a. American Express Authentication Verification Value (AEVV) (Block A) = “SUBSEQUENT000000000000000000”

b. Transaction ID (XID) (Block B) = blank

or


i. American Express Authentication Verification Value (AEVV) (Block A) = “SUBSEQUENT000000000000000000”

ii. Transaction ID (XID) (Block B) = blank


Response:


2. Format Indicator

a. Digital PAN (DN)





Subsequent Authorization, (Continued) Batch Request:


a. Action Code = AU

b. MOP = AX or JC


2. Extension Record




or

JCB Authentication (EJC005)



3. Product Record


Response:


2. Product Record






Recurring Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = AX or JC






or





Response:


2. Format Indicator

a. Digital PAN (DN)





Recurring Authorization, (Continued) Batch Request:


a. Action Code = AU

b. MOP = AX or JC


2. Extension Record




or




3. Product Record


Response:


2. Product Record






Reversal reverses a previously approved authorization..

Online Request:


a. Action Code = AR

b. MOP = AX or JC


Response:


Batch Request:


a. Action Code = AR

b. MOP = AX or JC


Response:






Original Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the accountholder's account and funds the merchant. Batch Request:


a. Action Code = DC

b. MOP = AX or JC


2. Extension Record


or


3. Product Record


Response:


2. Product Record






Recurring Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the accountholder's account and funds the merchant. Batch Request:


a. Action Code = DC

b. MOP = AX or JC


2. Extension Record




or




3. Product Record


Response:


2. Product Record






Original Deposit funds the merchant from a previously approved authorization.

Batch Request:


a. Action Code = DP

b. MOP = AX or JC


2. Extension Record


or


Response:


2. Product Record


Note: May be returned if an authorization is completed at deposit time.





Recurring Deposit funds the merchant from a previously approved authorization.

Batch Request:


a. Action Code = DP

b. MOP = AX or JC


2. Extension Record




or




Response:


2. Product Record

a. Digital PAN (PDN001) Note: May be returned if an authorization is completed at deposit time.





Refund returns the funds from the merchant for the previously approved deposit.

Batch Request:


a. Action Code = RF

b. MOP = AX or JC


Response:





Transaction Types and Requirements – Discover



a. Action Code = AU

b. MOP = DI



a. Discover Authentication (DA)

i. Cardholder Authentication Verification Value (CAVV) = cryptogram value for first transactions


Response:


2. Format Indicator

a. Digital PAN (DN) (Optional) Continued on next page



Transaction Types and Requirements – Discover, (Continued)

Original Authorization (Continued)

Batch Request:


a. Action Code = AU

b. MOP = DI


2. Extension Record

a. Discover Authentication (EDI002)

i. Cardholder Authentication Verification Value (CAVV) = cryptogram value for first transactions

3. Product Record


Response:


2. Product Record

a. Digital PAN (PDN001) (Optional) Continued on next page






a. Action Code = AU

b. MOP = DI




i. Cardholder Authentication Verification Value (CAVV) = “SUBSEQUENT000000000000000000”


Response:


2. Format Indicator

a. Digital PAN (DN) (Optional)





Subsequent Authorization, (Continued) Batch Request:


a. Action Code = AU

b. MOP = DI


2. Extension Record



3. Product Record


Response:


2. Product Record








a. Action Code = AU

b. MOP = DI






Response:


2. Format Indicator

a. Digital PAN (DN) (optional)





Recurring Authorization, (Continued) Batch Request:


a. Action Code = AU

b. MOP = DI


2. Extension Record



3. Product Record


Response:


2. Product Record







Online Request:


a. Action Code = AR

b. MOP = DI


Response:


Batch Request:


a. Action Code = AR

b. MOP = DI


Response:







a. Action Code = DC

b. MOP = DI


2. Extension Record


i. Cardholder Authentication Verification Value (CAVV) = cryptogram value

3. Product Record


Response:


2. Product Record








a. Action Code = DC

b. MOP = DI


2. Extension Record



3. Product Record


Response:


2. Product Record







Batch Request:


a. Action Code = DP

b. MOP = DI


2. Extension Record



3. Product Record


Response:


2. Product Record








Batch Request:


a. Action Code = DP

b. MOP = DI


2. Extension Record



Response:


2. Product Record

a. Digital PAN (PDN001) (Optional) Note: May be returned if an authorization is completed at deposit time.






Batch Request:


a. Action Code = RF

b. MOP = DI


Response:





Transaction Types and Requirements – MasterCard



a. Action Code = AU

b. MOP = MC




i. Accountholder Authentication Value (AAV) = cryptogram value for first transactions


Response:


2. Format Indicator

a. Digital PAN (DN) Continued on next page



Transaction Types and Requirements – MasterCard, (Continued)

Original Authorization, (Continued)

Batch Request:


a. Action Code = AU

b. MOP = MC


2. Extension Record


i. Accountholder Authentication Value (AAV) = cryptogram value for first transactions

3. Product Record


Response:


2. Product Record

a. Digital PAN (PDN001) Continued on next page






a. Action Code = AU

b. MOP = MC




i. Accountholder Authentication Value (AAV) = “SUBSEQUENT000000000000000000”


Response


2. Format Indicator

a. Digital PAN (DN)





Subsequent Authorization, (Continued)

Batch Request:


a. Action Code = AU

b. MOP = MC


2. Extension Record



3. Product Record

a. Digital PAN (DPN001) (Optional)

Response:


2. Product Record








a. Action Code = AU

b. MOP = MC






Response:


2. Format Indicator

a. Digital PAN (DN)





Recurring Authorization, (Continued)

Batch Request:


a. Action Code = AU

b. MOP = MC


2. Extension Record



3. Product Record


Response:


2. Product Record







Online Request:


a. Action Code = AR

b. MOP = MC


Response:


Batch Request:


a. Action Code = AR

b. MOP = MC


Response:




Transaction Types and Requirements - MasterCard, (Continued)



a. Action Code = DC

b. MOP = MC


2. Extension Record


i. Accountholder Authentication Value (AAV) = cryptogram value

3. Product Record


Response:


2. Product Record








a. Action Code = DC

b. MOP = MC


2. Extension Record



3. Product Record


Response:


2. Product Record







Batch Request:


a. Action Code = DP

b. MOP = MC


2. Extension Record


i. Accountholder Authentication Value (AAV) = cryptogram value

Response:


2. Product Record








Batch Request:


a. Action Code = DP

b. MOP = MC


2. Extension Record



Response:


2. Product Record

a. Digital PAN (PDN001) Note: May be returned if an authorization is completed at deposit time.






Batch Request:


a. Action Code = RF

b. MOP = MC


Response:


Transaction Types and Requirements – MasterCard using MST



a. Action Code = AU

b. MOP = MC

c. Transaction Type = R

2. Format Indicator

a. Retail 3 (R3)

Response:


2. Format Indicator

a. Digital PAN (DN)




Transaction Types and Requirements – MasterCard – DTVC

Original Authorization or Subsequent (Non-Recurring) Authorization using DTVC verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = MC



a. Fraud (FR)

i. Card Security Presence = 1

ii. Card Security Value must contain the DTVC Cryptogram

Response:


Batch Request:


a. Action Code = AU

b. MOP = MC


2. Product Record

a. Fraud (PFR001)


ii. Card Security Value must contain the DTVC Cryptogram

Response:





Transaction Types and Requirements – MasterCard – DTVC, (Continued)

Recurring Authorization using DTVC verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU

b. MOP = MC




i. Accountholder Authentication Value (AAV) must contain the Static Cryptogram.

Response:


Batch Request:


a. Action Code = AU

b. MOP = MC




i. Accountholder Authentication Value (AAV) must contain the Static Cryptogram.

Response:





Transaction Types and Requirements – ChaseNet and Visa



a. Action Code = AU

b. MOP = CR, CZ, or VI

c. Transaction Type = 5 (non-HCE) or 7 (HCE only)





Response:


2. Format Indicator

a. Digital PAN (DN)




Transaction Types and Requirements – ChaseNet and Visa, (Continued)

Original Authorization, (Continued) Batch Request:


a. Action Code = AU



2. Extension Record


or ChaseNet Authentication Signature Debit/Prepaid (ECR002)

or ChaseNet Authentication Credit (ECZ002)


3. Product Record


Response:


2. Product Record a. Digital PAN (PDN001)





Subsequent Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU






Response:


2. Format Indicator

a. Digital PAN (DN)

Batch Request:


a. Action Code = AU



2. Product Record


Response:


2. Product Record








a. Action Code = AU





i. Cardholder Authentication Verification Value must contain the Static Cryptogram


Response:


2. Format Indicator

a. Digital PAN (DN)

Batch Request:


a. Action Code = AU



2. Product Record


Response:


2. Product Record







Online Request:


a. Action Code = AR


c. Transaction Type = 2 or 5 (non-HCE) or 7 (HCE only)

Response:


Batch Request:


a. Action Code = AR



Response:





One Time Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the accountholder's account and funds the merchant. Batch Request:


a. Action Code = DC



2. Extension Record





3. Product Record


Response:


2. Product Record








a. Action Code = DC



2. Product Record


Response:


2. Product Record







Batch Request:


a. Action Code = DP



2. Extension Record





Response:


2. Product Record








Batch Request:


a. Action Code = DP



Response:


2. Product Record








Batch Request:


a. Action Code = RF



Response:


Transaction Types and Requirements – ChaseNet and Visa using MST



a. Action Code = AU



2. Format Indicator

a. Retail 3 (R3)

Response:


2. Format Indicator

a. Digital PAN (DN)




Transaction Types and Requirements – ChaseNet and Visa - DTVV

Original Authorization or Subsequent (Non-Recurring) Authorization using DTVV verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU




a. Fraud (FR)


ii. Card Security Value must contain the DTVV Cryptogram

Response:


Batch Request:


a. Action Code = AU



2. Product Record

a. Fraud (PFR001)


ii. Card Security Value must contain the DTVV Cryptogram

Response:





Transaction Types and Requirements – ChaseNet and Visa - DTVV, (Continued)

Recurring Authorization using DTVV verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU





i. Cardholder Authentication Verification Value (CAVV) must contain the Static Cryptogram.

Response:


Batch Request:


a. Action Code = AU



2. Extension Record


i. Cardholder Authentication Verification Value (CAVV) must contain the Static Cryptogram.

Response:






American Express, Discover, Discover Diners, JCB, MasterCard, and Visa / All currencies

ChaseNet / U.S. Currency



To Get Started



APPENDIX AN: CHASE PAY Introduction Chase Pay is an alternative checkout solution for online retailers and POS

merchants. Chase Pay allows Chase cardholders to store their credit and signature debit cards as payment methods for use in ecommerce and mobile commerce transactions. Chase Pay offers a streamlined checkout experience for participating Chase cardholders. At the same time, it provides merchants with secure processing through ChaseNet as card numbers will be tokenized and shipping/billing information can be provided on E-Commerce transactions.

How It Works - Chase Pay E-Commerce

The following section describes the process flow for Chase Pay E-Commerce processing.

1. On the merchant’s website, the customer selects the Chase Pay

button which is displayed via the Chase Pay script embedded in the merchant’s web page. The Chase Pay script is included in the Chase Pay Service Specification.

2. The merchant requests a session via the Chase Pay Service Specification.

3. The merchant receives a Digital Session ID. This Digital Session ID will be used by all subsequent request messages.

4. The Digital Session ID is validated and a Lightbox (iFrame) is displayed to the customer on the merchant’s website.

5. The accountholder authenticates with their Chase.com credentials and chooses a payment option from their digital wallet. The accountholder can also choose billing and/or shipping address information.

6. The Lighbox closes and control is returned to the merchant’s site. 7. The merchant sends a Chase Pay “GetCheckoutData” Message via

the Chase Pay Service Specification for payment option, billing, and/or shipping address information using the Digital Session ID.

8. Chase Pay Service returns data such as: Account number (DPAN) Token Requestor ID Cryptogram (authentication verification value) ECI (transaction type) Address information (Optional)

9. The merchant processes the authorization using the data returned from the Chase Pay Service via their standard transaction processing method.

Note: The original Token Requestor ID must be sent in by the Merchant for all transactions (i.e., Deposits, Reversals, Refunds, and Recurring) that are associated with the original authorization in order to identify the transaction as Chase Pay.



APPENDIX AN: CHASE PAY, (Continued)

How It Works – Chase Pay E-Comerce, (Continued)

Original Authorizations The DPAN value should be sent in the Account Number field. The <paymentCryptogram> value returned from the Chase Pay Service should be sent in the Cardholder Authentication Verification Value (CAVV) field. The <ecilndicator> value returned from the Chase Pay Service should be sent in the Transaction Type field or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). Subsequent Authorizations (i.e.. split/delayed shipments) The DPAN value should be sent in the Account Number field. The original <paymentCryptogram> value returned from the Chase Pay Service should be sent in the CAVV field. The original <ecilndicator> value returned from the Chase Pay Service should be sent in the Transaction Type field or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). Recurring Transactions The DPAN value should be sent in the Account Number field. Merchants must send the following static cryptogram in the CAAV field: "SUBSEQUENT000000000000000000 " or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data). The Transaction Type field must be populated with "2" or the transaction rejects with Response Reason Code 245 (Missing or Invalid Secure Payment Data).




How It Works – Chase Pay POS Using the Chase App – Show Processing

The following section describes the process flow for Chase Pay POS processing.

The following section describes the process flow for Chase Pay Retail Show processing using the Chase app.

1. Consumer shops at the merchant location and checks out as normal but indicates the desire to pay with Chase Pay.

2. The consumer opens the Chase Pay app and authenticates their credentials. The consumer then chooses the checkout option to communicate with the Chase Pay host to initiate a Chase Pay session and return the wallet contents, and a session ID. The consumer can use the default account or choose to override it with another account for this particular sale.

3. The Chase app renders a Visa standard QR code containing the DPAN, Exp Date, Cryptogram and Token requestor ID.

4. The Merchant POS unloads the contents of the QR code and communicates with the Merchant’s Payment Host.

5. The payment processing is performed BAU by the Payment Host via a connection to Merchant Services.

6. A response message is sent back to the Merchant, and all the way back to the merchant’s POS.

7. The merchant sends a confirmation message to Merchant Services with metadata to support post transaction services.

Note: EMV data is received by the merchant (either QR code or <PaymentInfo2>) encoded in Base 64 characters. This must be converted to Hexadecimal representation (i.e. ASCII 0-9, A-F) and submitted in the Chip Data field.




How It Works – Chase Pay POS Using the Merchant App – Show Processing


The following section describes the process flow for Chase Pay Retail Show processing using the Merchant app.

1. Consumer shops at the merchant location and checks out as normal but indicates the desire to pay with Chase Pay.

2. The consumer opens the Merchant app and authenticates. Then chooses the Chase Pay checkout option to communicate with the Chase Pay host to initiate a session and return the wallet contents, and a session ID. The consumer can use the default account or choose to override it with another account for this particular sale.

3. The Chase SDK (within the merchant App) renders a Visa standard QR code containing the DPAN, Exp Date, Cryptogram and Token requestor ID.

4. The Merchant POS unloads the contents of the QR code and communicates with the Merchant’s Payment Host.








How It Works – Chase Pay POS Using the Chase App – Scan Processing


The following section describes the process flow for Chase Pay Retail Scan processing using the Chase Pay app.

1. Consumer shops at the merchant location and checks out as normal but indicates desire to pay with Chase Pay.

2. The consumer opens the Chase Pay app and authenticates. Then chooses the checkout option to communicate with the Chase Pay host to initiate a Chase Pay session and return the wallet contents, and a session ID. The consumer can use the default account or choose to override it with another account for this particular sale.

3. The POS generates a QR code and the Consumer uses the Chase app to scan the code.

4. The Chase App sends the QR code to the Chase Pay host to identify the merchant and the merchant parameters.

5. Using those parameters, the Chase Pay host communicates to the Merchant’s Payment Host system with the QR code contents and the Chase Pay session ID.

6. The Payment Host uses the Session ID to retrieve the payment details from the Chase Pay host, including DPAN, Expiration Date, Cryptogram and Token requestor ID.

7. Independently the POS communicates with the Payment Host with basket info and total sale amount. The Payment Host can now match the cart with the consumer and their payment details.








How It Works – Chase Pay POS Using the Merchant App – Scan Processing

The following section describes the process flow for Chase Pay POS processing. The following section describes the process flow for Chase Pay Retail Scan processing using the Merchant app.

1. Consumer shops at the merchant location and checks out as normal but indicates desire to pay with Chase Pay.

2. The consumer authenticates to the merchant app and chooses Chase Pay. The Merchant app uses the Chase Pay SDK to authenticate with the Chase Pay host and retrieve the Session ID and the list of Chase Pay accounts. For each card, info will be returned to give the user confirmation that the right card was selected (nickname, last 4, etc). The default account will be identified but the consumer could be allowed to select a different account for this sale.

3. The POS generates a QR code and the Consumer uses the Merchant app to scan the code.

4. The Merchant app communicates with the Merchant’s Payment Host and sends the Session ID, Account Index and data from the QR code.

5. The merchant Payment Host uses the Session ID and Account Index to retrieve the payment details from the Chase Pay host, including DPAN, Expiration Date, Cryptogram and Token requestor ID.

6. Independently the POS communicates with the Payment Host providing basket info and total sale amount. The Payment Host can now match the cart with the consumer and the payment details.


8. A completion/response message is sent back to the Merchant, and all the way back to the merchant’s POS.






How It Works – Chase Pay POS Using the Merchant App – In App Processing

The following section describes the process flow for Chase Pay POS processing. The following section describes the process flow for Chase Pay Retail “In App” processing using the Merchant app.

1. Consumer uses the merchant app to purchase goods and selects to pay with Chase Pay.

2. The merchant app leverages the Chase Pay SDK to connect and authenticate to Chase Pay Services, where a Session ID is created, and the consumer selects a card from their wallet.

3. Merchant app sends Session ID and Order info information to Merchant’s Payment Host.

4. Merchant uses the GetCheckoutDetailsPOS API to request the payment info for the account selected by the consumer.

5. Chase returns the payment details (DPAN, Crypto, TRID, Token Exp date, Customer ID, etc).

6. Authorize transaction with the provided Payment data through the BAU connection to Merchant Services.

7. Completion/response messages are returned to the merchant

8. Confirmation messages are returned back to app.

9. A final confirmation is sent to Chase Pay with Receipt / Meta Data to support post transaction services.





Transaction Types and Requirements - Chase Pay E-Commerce

For all of the transaction types and requirements included in this section, the angle brackets ( < > ) indicate XML tags. Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU


c. Account Number Note: <accountNumber> value returned from the Chase Pay Service

d. Transaction Type = <eciIndicator> value returned from the Chase Pay Service


a. Digital PAN (DN)

i. Token Requestor ID Note: <tokenRequestorID> value returned from the Chase Pay Service

b. Visa Authentication (VA )

i. Cardholder Authentication Verification Value (CAVV) Note: <paymentCryptogram> value returned from the Chase Pay Service

Response:


2. Format Indicator

a. Digital PAN (DN)




Transaction Types and Requirements – Chase Pay E-Commerce, (Continued)

Original Authorization verifies the accountholder's open to buy and reserves it. Batch Request:


a. Action Code = AU




2. Extension Record





3. Product Record



Response:


2. Product Record






Subsequent Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU





a. Digital PAN (DN)


b. Visa Authentication (VA)


Response:


2. Format Indicator

a. Digital PAN (DN)





Subsequent Authorization verifies the accountholder's open to buy and reserves it. Batch Request:


a. Action Code = AU




2. Extension Record





3. Product Record



Response:


2. Product Record








a. Action Code = AU


c. Account Number Note: <accountNumber> value returned from the original authorization from the Chase Pay Service

d. Transaction Type = 2


a. Digital PAN (DN)

i. Token Requestor ID Note: <tokenRequestorID> value returned from the original authorization the Chase Pay Service

b. Visa Authentication (VA )

i. Cardholder Authentication Verification Value = “SUBSEQUENT000000000000000000”

Response:


2. Format Indicator

a. Digital PAN (DN)





Recurring Authorization verifies the accountholder's open to buy and reserves it. Batch Request:


a. Action Code = AU




2. Extension Record





3. Product Record


i. Token Requestor ID Note: <tokenRequestorID> value returned from the original authorization from the Chase Pay Service

Response:


2. Product Record






Reversal reverses a previously approved authorization. Online Request:


a. Action Code = AR



d. Transaction Type = 2 or 7


a. Digital PAN (DN)


Response:


2. Format Indicator

a. Digital PAN (DN)





Reversal reverses a previously approved authorization. Batch Request:


a. Action Code = AR



d. Transaction Type = 2 or 7

2. Product Record



Response:


2. Product Record






One Time Conditional Deposit verifies accountholder's open-to-buy and if the funds are available, debits the accountholder's account and funds the merchant. Batch Request:


a. Action Code = DC




2. Extension Record





3. Product Record



Response:


2. Product Record








a. Action Code = DC




2. Extension Record





3. Product Record



Response:


2. Product Record







Batch Request:


a. Action Code = DP




2. Extension Record

a. Visa Authentication (EVI002) (Optional)




3. Product Record



Response:


2. Product Record







Batch Request:


a. Action Code = DP




2. Extension Record





3. Product Record



Response:


2. Product Record






Refund returns the amount to the accountholder’s account.

Batch Request:


a. Action Code = RF




2. Product Record



Response:


2. Product Record





Transaction Types and Requirements - Chase Pay POS

For all of the transaction types and requirements included in this section, the angle brackets ( < > ) indicate XML tags. Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AU


c. Account Number Notes: For Chase Pay POS (Show), this value is derived from the EMV tag 57 read from the QR code. For Chase Pay POS (Scan), this value is derived from <track2Equivalent> from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

d. Transaction Type = R


a. Chip EMV® (CP)

i. For Chase Pay POS (Show) this field must be populated with the EMV tags and values read from the QR code.

ii. For Chase Pay POS (Scan) this field must be populated with the <paymentInfo2> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

b. Digital PAN (DN)

i. Token Requestor ID Notes: For Chase Pay POS (Show) this field must be populated with the value received in EMV tag 9F19 read from the QR code. For Chase Pay POS (Scan) this field must be populated with the <tokenRequestorID> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.




Transaction Types and Requirements – Chase Pay POS, (Continued)

Authorization (Continued), Online (Continued)

Request:

c. Retail 2 (R2)

i. Terminal ID

d. Retail 3 (R3)

i. POS Capability Code = 7

ii. POS Entry Mode = 03

iii. Track Indicator = 2

iv. Swipe Data Notes: For Chase Pay POS (Show) this field must be populated with the value received in EMV tag 57 read from the QR code. For Chase Pay POS (Scan) this field must be populated with the <track2Equivalent> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

Response:



a. Chip EMV® (CP)

b. Digital PAN (DN)

c. Visa Transaction Identifier (VI)




Transaction Types and Requirements – Chase Pay POS, (Continued)

Reversal reverses a previously approved authorization. Online Request:


a. Action Code = AR





a. Digital PAN (DN)

i. Token Requestor ID Notes: For Chase Pay POS (Show) this field must be populated with the value received in EMV tag 9F19 read from the QR code. For Chase Pay POS (Scan) this field must be populated with the <tokenRequestorID> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.


i. Response Date = approved, original, authorized date ii. Authorization Code = approved, original, authorization

code

Response:

1. Online Processing Return Format Indicator


a. Digital PAN Reply Format Indicator (DN)




Transaction Types and Requirements – POS, (Continued)


Batch Request:


a. Action Code = DP




2. Extension Record

a. Visa (EVI001) (Optional)

or ChaseNet Signature Debit/Prepaid (ECR001)

or ChaseNet Credit (ECZ001)

3. Product Records

a. Chip EMV® (PCP010) (Optional)

Notes: For Chase Pay POS (Show) this field must be populated with the EMV tags and values read from the QR code. For Chase Pay POS (Scan) this field must be populated with the <paymentInfo2> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

b. Digital PAN (PDN001)

i. Token Requestor ID





Deposit (Continued)

Batch (Continued)

Notes: For Chase Pay POS (Show) this field must be populated with the value received in EMV tag 9F19 read from the QR code.

For Chase Pay POS (Scan) this field must be populated with the <tokenRequestorID> value returned from the Chase Pay Platform API GetCheckoutDataPOS2 response message.

Response:


2. Extension Record (Optional)

a. Visa (EVI001) or

b. ChaseNet Signature Debit/Prepaid (ECR001) or

c. ChaseNet Credit (ECZ001)

3. Product Record

a. Digital PAN (PDN001) b. Chip EMV (PCP010) (Optional)





Refund returns the amount to the accountholder’s account.

Note: Refunds are not processed as Chase Pay POS transactions. Merchants should use their standard refund process.

Batch Request:


a. Action Code = RF



Response:





Online Format Examples


1. Input record layout example for Chase Pay Point of Sale (POS) Authorization: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74VABC123456789DEF VI4266841007232448 04200000123456000000007575840R AU CP128 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 aEFlZ0FBQUFBeEFRbjI0RU1EQXdNSjk4QkFFcStBR0NBZ0FBbnhBU0VVUURjQUFBQUFBQUFBQUFBQVlqUndBQW55WU

18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 1FalJKMkxtbkg2V2ZOZ01BQVo4M0JGY0 dwOU09DN 40010074892 R2 87654 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 321R37032294266841007232448D170420100000↵

1. Return record layout example for Chase Pay Point of Sale (POS) Authorization:

1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100160711TST123 4266841007232448 0420VI 000000007575CP128 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 aEFlZ0FBQUFBeEFRbjI0RU1EQXdNSjk4QkFFcStBR0NBZ0FBbnhBU0VVUURjQUFBQUFBQUFBQUFBQVlqUndBQW55WU 18 19 20 21 22 23 24 25 26 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 1FalJKMkxtbkg2V2ZOZ01BQVo4M0JGY0 dwOU09DN 40010074892 VI0000000075 27 28 29 30 31 32 33 34 35 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 75123403001123456789012345111111 ↵



Online Format Examples (Continued)

2. Input record layout example for Chase Pay Point of Sale (POS) Authorization Reversal: 1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 P74V ABC123456789DEF VI4266841007232448 04200000123456000000007575840R AR DN 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 40010074892 PA160711TST123 ↵

2. Return record layout example for Chase Pay Point of Sale (POS) Authorization Reversal:

1 2 3 4 5 6 7 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 T74VABC123456789DEF 100160711TST123 4266841007232448 2004VI 000000007575 DN 9 10 11 12 13 14 15 16 17 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 40010074892 ↵


AN: CHASE PAY, (Continued)

Batch Format Examples

Sample Input File 1: Sample Input File 1: 1 2 3 4 5 6 7 8 9 10 11 12 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 PID=123456 XYZCO SID=123456 XYZCO START 031202 3.0.0 DEPFILE [ 1] MXYZ*PYMT1OF3 [ 2] S00001234569898981234AUTH AUVI4123456789012345 1220000000000100840 1 MERCHSPC [ 3] PFR001321 1 [ 4] ABJOHN D. *SMITH W6038968000 US [ 5] A24 NORTHEASTERN BLVD [ 6] A3SALEM, NH 03079 [ 7] M [ 8] S00001234569898981234DEP DPMC5412345678901234 1204000000001000840100R 031130877865 [ 9] EMC001901E1 123456ABC 00000000757511154321 [10] S00001234569898981234REFUND RFDI6011345678901234 12040000000020008401001 031130 [11] ABSAM *BROWNE D6035554444 US [12] A223 NORTH POLICY RD [13] A3SALEM, NH 03079-9099 [14] S00001234569898981234ECP VDEC12344321765612 000000003000840 1 [15] EEC001012345678CB [16] AMJOHN *DOE [17] S00001234569898981234PURCH DCVI4123456789012345 1204000000015797840 1 [18] PPC001CUSTREF123456789 000000000000 [19] ABTHE BIG COMPANY W60355588880810US [20] A254 NORTHWEST RD [21] A3SALEM, NH 03079-9099 [22] AS03053 [23] S00001234569898981234SALE DPAX373235387881007 12040000000005008401001 031130654321 [24] EAX001XYZ COMPANY PRODUCT1 XYZ COMPANY PRODUCT2 [25] EAX002XYZ COMPANY PRODUCT3 XYZ COMPANY PRODUCT4 [26] PPC001ABC123 000000000000 [27] ABLINUS *LONGHORN D6035554444 [28] A223 NORTH POLICY RD [29] A3SALEM, NH 03079-9099 [30] AS03079-9099 [31] S00001234569898981234SALEDEBIT DPSP4543210987654321 000000007575840100I 031130 [32] PDE00112345678 [33]




Batch Format Examples (Continued) Sample Input File 1: Sample Input File 1, (Continued): 1 2 3 4 5 6 7 8 9 10 11 12 S0000123456ABC123456789DEF DPVI4266841007232448 0420000000007575840100R 160711TST123 DEPCPPOS [34] PDN001 40010074892 [35] S0000123456ABC123456789DEF RFVI4266841007232448 0420000000005000840 R 160711 REFCPPOS [36] B RECS=000000036 ORDS=000000009 $TOT=00000000042547 $SALE=00000000035447 $REFUND=00000000007000 [37] T RECS=000000037 ORDS=000000009 $TOT=00000000042547 $SALE=00000000035447 $REFUND=00000000007000 [38] PID=123456 XYZCO SID=123456 XYZCO END 031202 [39] EOFEOFEOF [40] 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 9 10 11 12

Please see the following page for Sample Input File 1 Line Item Description Continued



Batch Format Examples (Continued) Sample Input File 1 Line Item Description: Line 1: Header Record Line 2: Merchant Descriptor [populated] Line 3: Detail Record [Visa authorization with address verification & fraud] Line 4: Product Record [Fraud record for Visa CVV2] Line 5-7: Address Record [With billing address] Line 8: Merchant Descriptor [blank – resets descriptor to the transaction division default] Line 9: Detail Record [MasterCard deposit, auth info. included, retail transaction] Line 10: Extension Record: MasterCard Line 11: Detail Record [Discover refund] Line 12-14: Address Record [With billing address] Line 15: Detail Record [Validate, Verify, & Deposit for a ACH (ECP) transaction] Line 16: Extension Record: Electronic Check Processing Line 17: Address Record [With consumer’s checking account name] Line 18: Detail Record [Visa conditional deposit for a Procurement Card] Line 19: Product Record: Procurement (Level 2) Line 20-22: Address Record [With bill-to-address] Line 23: Address Record [With ship-to-address postal code code] Line 24: Detail Record [American Express deposit for a Procurement Card with TAA’s] Line 25-26: Extension Record: American Express [1 and 2] Line 27: Product Record: Procurement (Level 2) Line 28-30: Address Record [With bill-to-address] Line 31: Address Record [With ship-to-address postal code code] Line 32: Detail Record [Star PINless Debit Deposit] Line 33: Product Record [PINless Debit]



Batch Format Examples (Continued) Sample Input File 1 Line Item Description, (Continued): Line 34 Detail Record [Chase Pay POS Deposit] Line 35: Product Record [Digital for TRI] Line 36: Detail Record [Chase Pay Refund] Line 37: Batch Totals Record Line 38: Totals Record Line 39: Trailer Record Line 40: EOFEOFEOF (Note: only required for TCPIP protocol)




Batch Format Examples (Continued) Sample Output File 1: 1 2 3 4 5 6 7 8 9 10 11 12 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 PID=123456 XYZCO SID=123456 XYZCO START 031202 3.0.0 DEPFILE [ 1] S00001234569898981234AUTH AUVI4123456789012345 12040000000001008401001M031202567890I4N MERCHSPC [ 2] S00001234569898981234DEP DPMC5412345678901234 1204000000001000840100R 031130877865 Y [ 3] S00001234569898981234REFUND RFDI6011345678901234 12040000000020008401001 031130 Y [ 4] S00001234569898981234ECP VDEC12344321765612 0000000030008402391 031202 N [ 5] S00001234569898981234PURCH DCVI4123456789012345 12040000000157978401001 031202234567I4Y [ 6] S00001234569898981234SALE DPAX373235387881007 12040000000005008401001 031130654321 Y [ 7] S00001234569898981234SALEDEBIT DPSP4543210987654321 000000007575840100I 031130 Y [ 8] S0000123456ABC123456789DEF DPVI4266841007232448 0420000000007575840100R 160711TST123 Y DEPCPPOS [9] S0000123456ABC123456789DEF RFVI4266841007232448 0420000000005000840 R 160711 Y REFCPPOS [10] B RECS=000000036 ORDS=000000009 $TOT=00000000042547 $SALE=00000000035447 $REFUND=00000000007000 [11] T RECS=000000037 ORDS=000000009 $TOT=00000000042547 $SALE=00000000035447 $REFUND=00000000007000 [12] PID=123456 XYZCO SID=123456 XYZCO END 031202 [13] EOFEOFEOF [14] 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 9 10 11 12

Please see the following page for Sample Output File 1 Line Item Description




Batch Format Examples (Continued) Sample Output File 1 Line Item Description: Line 1: Header Record Line 2: Detail Record [Visa authorization with address verification & fraud] Result Line 3: Detail Record [MasterCard deposit, auth info. included, retail transaction] Result Line 4: Detail Record [Discover refund] Result Line 5: Detail Record [Validate, Verify, & Deposit for a ACH (ECP) transaction] Result Line 6: Detail Record [Visa conditional deposit for a Procurement Card] Result Line 7: Detail Record [American Express deposit for a Procurement Card with TAA’s] Result Line 8: Detail Record [Star PINless Debit Deposit] Line 9: Detail Record [Chase Pay POS Deposit] Result Line 10: Detail Record [Chase Pay POS Refund] Result Line 11: Batch Totals Record Line 12: Totals Record Line 13: Trailer Record Line 14: EOFEOFEOF (Note: only required for TCPIP protocol on inbound, but created for all protocols on outbound unless otherwise

requested.)

Notes: If an RFR record is received by Chase, and there is no file available for pick up, the following message is given: YY-MM-DD HH:MM:SS No data to send back at this time. EOFEOFEOF

– Message is sent in text file format without header or PID information and begins in position 2 – TCPIP merchants receives entire message noted above, with the EOF line – Bsync merchants receives message above, without the EOF line

RFR is a separate record sent to Chase. It should not be sent as part of the input data file.




Appendix AL: ChaseNet

Chase Pay Service Specification

Chase Pay Platform API Specification

Chase Pay QR Code Specification

Chase Pay Mobile SDK Guide


ChaseNet, Visa / U.S. Dollars



To Get Started

Contact your Chase Representative.


APPENDIX AO: DIRECT PAY Introduction Direct Pay consists of a set of transactions that allow a merchant or person

to transfer funds to one or more people.

There are two types of Direct Pay business application identifiers which can be specified:

• “AA” - Business to Person payment • “PP” - Person to Person payment • “LO” - Loyalty and Offers • “CP” - Card Bill Payment • “FD” - Funds Disbursement • “GD”- Government Disbursement • “MD”- Merchant Disbursement • “TU” - Top Up (pre-paid card loads) • “BI” - Bank Initiated • “WT” - Wallet Transfer

Direct Pay functionality is supported by two transaction events:

• Account Funding Transaction (AFT) • Original Credit Transaction (OCT)

The AFT transaction set (including authorization and deposit action codes) allow the merchant to receive funds through a money transfer transaction from a cardholder account (“sender”). The OCT Transaction allows the Merchant to credit funds to one or more cardholder accounts (“recipient(s)”). It is important to note, that AFT and OCT transactions are independent of each other. Although, often an AFT transaction precedes a corresponding OCT, the use of AFT and OCT transactions combinations are determined by the Merchant.

Typically, credit / debit transactions are initiated by merchants to be used for payments of merchant goods and services by cardholders. Direct Pay is different. Instead, the merchant provides a service to the cardholders, by issuing the AFT and/or OCT transactions to move money from and to a cardholder. No merchant goods are involved.

Direct Pay examples include:

• Splitting a restaurant tab between three individuals, where person-A pays the entire tab and person-B and person-C reimburse person-A for their portion of the bill via an AFT and OCT transaction combination.

• Disbursing refunds to subscribers such as a Merchant issuing a credit to one or more of their customers directly onto their credit card.

Rather than use traditional methods such as a check or money order the Direct Pay process allows the use of existing credit card processing infrastructure to accomplish payments.



APPENDIX AO: DIRECT PAY (Continued)

How It Works In order for the merchant to use the Direct Pay functionality the following is required:

• Merchant must be enabled for Direct Pay support at the Transaction Division. The merchant can be enabled for AFT Only, OCT Only or both AFT and OCT transactions.

• The MCC must be 4829. • The MCC must be 6012 when a value of BI is present in the Business

Application Identifier field. • The Direct Pay Action Codes must be used when performing Direct

Pay transaction. • The MOP must equal VI. • The Direct Pay Format Indicator (DP) must be sent with all Online

Direct Pay transactions. Soft Merchant Information Format Indicators SM, S2, S3, or S4 should also be sent for OCT transactions.

• The Product Record: Direct Pay 1 (PDP001) must be sent for all batch AFT transactions. The Product Record: Direct Pay 1 (PDP001) and Product Record: Direct Pay 2 (PDP002) must be sent for all batch OCT transactions. Product Record: Soft Merchant Information 1 (PSM001) should also be sent for OCT transactions.

The AFT transaction set follows standard credit card processing, requiring an AFT authorization and an AFT deposit. This allows the cardholder to transfer funds from their individual cardholder account to the merchant.

• In this scenario, the cardholder (“sender”) directs the merchant to initiate the AFT authorization for approval.

• Upon approval the merchant then sends an AFT deposit transaction to complete the transaction set and move the monies from the cardholder to the merchant account.

Note: The AFT transaction amount should include the amount to be transferred inclusive of service and foreign exchange fees.

Different from the AFT, the OCT transaction is a single transaction performed by the merchant to credit the recipient cardholder’s account.

• The merchant sends in an OCT transaction and the funds are credited to the recipients account immediately.

• Then merchant funding is decremented by the OCT transaction amount.




Transaction Types and Requirements for AFT

AFT Authorization verifies the accountholder's open to buy and reserves it. Online Request:


a. Action Code = AA

b. MOP = VI

2. Format Indicator

a. Direct Pay (DP)

i. Business Application Identifier

Response:





Transaction Types and Requirements for AFT, (Continued)

AFT Authorization, (Continued) Batch Request:


a. Action Code = AA

b. MOP = VI

2. Extension Record

a. Direct Pay (PDP001)


Response:





Transaction Types and Requirements for AFT, (Continued)

AFT Deposit deposits the transaction upon approval. Batch Request:


a. Action Code = AD

b. MOP = VI

2. Extension Record



Response:





Transaction Types and Requirements for OCT

Reduces the merchants funding account and credits the cardholders account. Online Request:


a. Action Code = AO

b. MOP = VI


a. Direct Pay (DP)

i. Business Application Indicator

ii. Sender Reference Number

iii. Source of Funds

iv. Recipient Name

v. Sender Name

vi. Sender Street Address

vii. Sender City

viii. Sender State

ix. Sender Zip Code (Optional)

x. Sender Country Code

b. Soft Merchant Information, Soft Merchant Information 2, Soft Merchant Information 3, or Soft Merchant Information 4 (Optional)

i. DBA

Response:





Transaction Types and Requirements for OCT, (Continued)

Reduces the merchants funding account and credits the cardholders account. Batch Request:


a. Action Code = AO

b. MOP = VI

2. Extension Record



ii. Sender Reference Number

iii. Source of Funds

iv. Recipient Name

b. Direct Pay 2 (PDP002)

i. Sender Name

ii. Sender Street Address

iii. Sender City

iv. Sender State

v. Sender Zip Code (Optional)

vi. Sender Country Code

c. Soft Merchant Information 1 (PSM001) (Optional)

i. DBA

Response:






Visa / U.S. Dollars



To Get Started

Contact your Chase Representative.


APPENDIX AP: CHIP EMV® Introduction EMV® is a global standard for credit and debit payment cards based on chip

card technology. EMV® chip-based payment cards, also known as smart cards, contain an embedded microprocessor, a type of small computer. The microprocessor chip contains the information needed to use the card for payment, and is protected by various security features. EMV® may also be referred to as “chip and pin” or “chip and signature”.

How It Works EMV® data between card and device is generally in binary format, commonly

referred to as BER-TLV (Basic Encoding Rules-Tag Length Value). It must be converted to ASCII format by the merchant prior to submitting to Chase. All data must be submitted in single byte ASCII, unless otherwise stated.

There are several types of machines used for EMV® processing at the point of sale. Specific fields within the EMV® product records may be required based on the type of machine. For further information, please contact your Chase representative. Authorization Processing

When an online transaction using EMV® occurs the data from the chip on the card is transferred to the device that read the card. The data from the chip is translated and formatted to a Chase format. The transaction is then sent to Chase.

EMV® authorizations are available only via online processing.

Deposit Processing

Chase does not store the EMV® data that was sent on an online transaction. The merchant should provide the EMV® authorization data on all deposit transactions. If this data is not sent at deposit time, the transaction does not reject, but the transaction may not qualify for the best interchange and may cause chargeback liability to be assigned to the merchant.



APPENDIX AP: CHIP EMV®, (Continued) How It Works, (Continued)

EMV® is supported for the following Online MOP and Action Code combinations


AX American Express AR, AU, BI, FA, VF

CR ChaseNet - Signature Debit AR, AU, BI, FA, VF

CZ ChaseNet - Credit AR, AU, BI, FA, VF

DD Discover Diners AR, AU, BI, FA, VF

DE Generic PIN-Based Debit DR, PA, PR, RA

DI Discover AR, AU, BI, FA, VF

IM International Maestro AR, AU, BI, FA, VF

JC Japan Credit Bureau (available October 2015)

AR, AU, BI, FA, VF

MC MasterCard AR, AU, BI, FA, VF

MR MasterCard Restricted Canadian Debit

AR, AU, BI, FA, VF

VI Visa AR, AU, BI, FA, VF

VR Visa Restricted Canadian Debit

AR, AU, BI, FA, VF

Note: Chip data sent on Action Code = AR, BI, FA, VF is not passed to the card brand.



APPENDIX AP: CHIP EMV®, (Continued) How It Works, (Continued)

EMV® is supported for the following Batch MOP and Action Code combinations


AX American Express DP, RF

CR ChaseNet - Signature Debit DP, RF

CZ ChaseNet - Credit DP, RF

DD Discover Diners DP, RF

DI Discover DP, RF

IM International Maestro DP, RF

JC Japan Credit Bureau (available October 2015)

DP, RF

MC MasterCard DP, RF

MR MasterCard Restricted Canadian Debit

DP, RF

VI Visa DP, RF

VR Visa Restricted Canadian Debit

DP, RF

Specific PIN-Based Debit

Reference MOP field in the Detail Record (“S” Record Input)

DP, RF

Note: Chip data sent on Action Code = RF is not passed to the card brand.

Fallback Values

There are two scenarios where fallback can occur.

Scenario 1 – Device cannot connect to Chase The chip and device decide to continue with the transaction. Typically this is for a low dollar amount transaction. The chip is enabled by the issuer to support this. However, Chase POS download sets all fallback values to zero dollars. As a result, the transaction is declined.

Scenario 2 – Device can connect to Chase Chip data is read but cannot be processed as chip. The transaction is processed as swipe.



APPENDIX AP: CHIP EMV®, (Continued) Fallback Values, (Continued)


Device Capability

Presentation Method

POS Capability Code POS Entry Mode Track Indicator

Chip and Contactless Capable

Insert attempted, fall back to Track 1 from swiped

7 – Magnetic stripe reader, key entry, chip reader and RFID reader

80 – Chip card, fall back to magnetic stripe read

1 – Track 1


Insert attempted, fall back to Track 2 from swiped



2 – Track 2


Insert attempted, swipe attempted, fall back to keyed/ manually entered


79 – Chip card, fall back to manually entered

N/A

Chip (but not Contactless) Capable

Insert attempted, fall back to Track 1 from Swiped


-OR- 3 – Magnetic stripe reader

and chip reader only


1 – Track 1


Insert attempted, fall back to Track 2 from Swiped


-OR- 3 – Magnetic stripe reader

and chip reader only


2 – Track 2


Insert attempted, swipe attempted, fall back to manually entered


79 – Chip card, fall back to manually entered

N/A



APPENDIX AP: CHIP EMV®, (Continued) Transaction Types and Requirements

Online Request:

1. Online Processing Detail Record a. Action Code =AR, AU, BI, FA, VF

2. Format indicators a. Chip EMV® (CP) (optional)

Note: Required when Action Code = AU b. Retail 3 (R3)

Response: 1. Online Processing Return Format Record 2. Format Indicator

a. Chip EMV® (CP) (Optional) Note: Returned when Action Code = AU

Batch

Request:


a. Action Code = DP, RF

2. Product Record

a. Chip EMV® (PCP010 - 019) (Optional, should be sent for Deposit)

Response:




APPENDIX AP: CHIP EMV®, (Continued)


Chip EMV® Download EMV Implementation Guide


American Express, ChaseNet, Discover, Discover Diners, MasterCard, Visa, / All currencies



To Get Started Contact your Chase Representative.


APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS

Introduction In addition to the generation of a transaction via a cardholder initiated event, there is a significant segment of transactions where a merchant, payment facilitator (PF) or staged digital wallet operator (SDWO) uses a cardholder’s payment credentials (i.e., account details) that were previously stored for future purchases. A stored credential is information (including, but not limited to, an account number or payment token) that is stored by a merchant or its agent, a payment facilitator, or a staged digital wallet operator to process future transactions.

With the introduction of the Stored Credential and Merchant Initiated Transaction Framework, data is presented with authorizations and transactions to identify stored credentials and indicate cardholder consent was obtained. Within these frameworks, transactions are presented as either a Cardholder Initiated Transaction (CIT) or Merchant Initiated Transaction (MIT). Note: Within this Framework, Merchants are responsible for receiving and retaining the Transaction ID (TXID) for use on subsequent transactions.

How It Works Credential versus Stored Credential

When a Credential is used for a single one time use, that transaction is considered out of the Stored Credential Framework. If a Credential is instead used to set up a cardholder account that will support future purchases, that Credential use is considered within the Stored Credential Framework. The initial use of a Credential within the Framework is initiated by the cardholder, and creates a Stored Credential. The Stored Credential is intended to support more than one transaction.

All stored credential transactions must be part of the Framework. However, not all credential transactions will necessarily be part of the Framework. To use a stored credential for a transaction, either a CIT or MIT can be submitted. When initiating a transaction using the Framework, the appropriate message type must be sent.



APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS, (Continued)


The following table illustrates the parameters when using both Credentials and Stored Credentials within the Framework. Comparison of Credentials in Framework Credential Within Framework Stored Credential Within Framework First transaction initiated by the cardholder/customer

Can also be used to complete a single transaction or single purchase. For example, a split shipment

Payment Token or PAN (Primary Account Number)

Account (Stored Credential) will be used for future purchases, such as card on file, wallet, recurring, etc.

Future purchases will use stored information

Stored Credential can be Payment Token or PAN (Primary Account Number)

A stored credential can be used by either a cardholder or merchant

Merchant must follow cardholder disclosure and consent requirements

Cardholder-Initiated Transaction (CIT) With a CIT, the consumer is present and provides their payment credentials for the transaction. A CIT can be submitted through a terminal in store or an online checkout. CITs include proof that the cardholder was involved in the transaction (cardholder validation performed - CVV2, chip data, etc.). A CIT can be performed with a PAN or payment token. A CIT can be initiated to complete a purchase or create a stored credential.

• If an amount is due at the time credentials are stored, the CIT is submitted as an authorization for a purchase transaction

• If no amount is due when the credentials are stored, submit the CIT as an Account Verification





Merchant-Initiated Transaction (MIT) An MIT is a transaction that relates to a previous CIT but is conducted without the consumer present and without cardholder validation performed. The MIT must refer to a consumer’s original interaction and include the information from a prior CIT. Through an MIT, a merchant can initiate a transaction without the cardholder’s participation. Categories for MITs include:

• Standing-Instruction MITs support pre-agreed cardholder instructions for ongoing purchases of goods or services. Standing Instruction MITs are a follow-up to a CIT; for example, an Unscheduled Credential-on-File (COF) Transaction such as adding funds to a wallet account.

• Industry-Specific Business Practice MITs support transaction types that are a follow-up to an original cardholder-merchant interaction that was not completed with one single transaction; for example, a Reauthorization (Split Shipment) Transaction.

Merchant Obligations for Managing Transaction ID In order to properly process a transaction within the Framework, merchant identification of an authorization as a CIT or MIT is required in order to receive additional data back in the authorization response message. This data includes the Transaction ID (TXID), a value created by Visa at the time of authorization. Merchant support of the receipt of authorization Transaction IDs, fields and data not previously provided in authorization response messages is required. Depending on the type of message, one or two Transaction IDs (TXIDs) will be provided in authorization response messages. In addition, merchant storage of these TXIDs is required for future use to supply to Chase when completing a MIT authorization message. The Transaction ID generated at the time of a CIT is provided with a subsequent corresponding MIT; this TXID will "link" the CIT and MIT together. With the MIT, merchant identification of a MIT, the type of MIT message, and the TXID previously supplied with the CIT in ongoing MIT authorization messages is required. With an initial CIT authorization response sent back to the merchant, a TXID is included in the Response TXID field. This Response TXID must be stored by the merchant and included in the Submitted TXID field when submitting a MIT transaction. Authentication Data Considerations For requirements related to the submission of cryptogram data, refer to Appendix AM: Consumer Digital Payment Token of the processing format technical specifications.





Message Type Relationships


APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS, (Continued) Message Type Grid The following table contains details about each message type. Please refer to this table for this information:

Code Name Description Initiated by

Submitted TXID

required? Stored

Credential

CSTO Cardholder-Initiated Stored Credential

Signifies that the merchant is storing the cardholder credentials for the first time in anticipation of future stored credential transactions.

Example: A cardholder sets up a customer profile for future purchases.

Cardholder N Optional

CUSE Cardholder-Initiated Credential on File

Signifies a cardholder initiated transaction using a credential that is stored at the merchant.

Example: A purchase made by a cardholder at an online retailer with the cardholder’s credential on file.

Cardholder N Required

MUSE Merchant-Initiated Unscheduled Credential On File

Signifies an unscheduled transaction initiated by the merchant, i.e., not a recurring transaction that occurs at a scheduled interval.

Example: Subsequent authorization for an electronic toll collection device when the stored balance drops below a predefined threshold.

Merchant Y Required

CREC Cardholder-Initiated Recurring Transaction

Signifies a cardholder initiating the first of a recurring series of transactions.

Example: A cardholder sets up billing for an ongoing monthly gym membership.





Submitted TXID

required? Stored

Credential

MREC Merchant-Initiated Recurring Transaction

Signifies a transaction in a series of transactions processed at fixed, regular intervals (not to exceed one year between transactions). These transactions represent an agreement between a cardholder and a merchant to initiate future transactions for the purchase of goods or services provided at regular intervals.

Example: A magazine publisher charges the cardholder for a monthly subscription.

Merchant Y Required

CEST Cardholder-Initiated Estimated Authorization Amount

Signifies when an authorization amount is estimated and may not match the completed transaction amount.

Example: A hotel uses an estimated authorization to reserve the predicted amount of the hotel stay.


MINC Merchant-Initiated Incremental Authorization

Signifies when a merchant needs to increase the authorized amount on a previously approved authorization.

Example: A hotel merchant submits an incremental authorization to increase the total amount authorized to accommodate an extended stay. Note: This functionality is intended for use by Merchant Category Codes listed in the Industry support for incremental authorizations table.

Merchant Y Optional




Submitted TXID

required? Stored

Credential

CINS Cardholder-Initiated Installments

Signifies a cardholder initiating the first of a series of installment payments.

Example: A cardholder sets up an agreement with a merchant to initiate one or more future transactions over a period of time for a single purchase of a good or service.


MINS Merchant-Initiated Installment Transaction

Signifies a transaction in a series of transactions that use a stored credential and that represents a cardholder agreement for the merchant to initiate one or more future transactions over a period of time for a single purchase of a good or service.

Example: A furniture retailer allows a cardholder to pay for goods purchased in installments over a pre-agreed period of time.

Merchant Y Required

CGEN Cardholder-Initiated General Transaction

Signifies cardholder-initiated transactions that can support various merchant-initiated transactions.

Example: A cardholder-initiated authorization that the merchant may later use to request a re-authorization.


MRSB Merchant-Initiated Resubmission

Signifies when a merchant performs a resubmission in cases where the merchant requested an authorization, but received a decline after the merchant has already delivered the goods or services to the cardholder.

Example: A merchant receives a decline due to insufficient funds after already shipping goods and performs a resubmission transaction to obtain an approval.

Merchant Y Optional




Submitted TXID

required? Stored

Credential

MDEL Merchant-Initiated Delayed Charges

Signifies when a delayed charge transaction is performed to process an additional transaction after the original services have been rendered and the payment for the initial services has been processed.

Example: A lodging merchant performs a delayed charge transaction to bill the cardholder for incidental charges after the cardholder has checked out.

Merchant Y Optional

MRAU Merchant-Initiated Reauthorization

Signifies a merchant-initiated re-authorization.

Example: Merchant receives an order for several items totaling a specific amount. The items are shipped separately and split shipment transactions are created for each shipment.

Merchant Y Optional

MNOS Merchant-Initiated No-Show

Signifies a no-show transaction when a cardholder does not comply with the merchant’s cancellation policy.

For merchants to submit a No-Show transaction through the framework, including merchants that accept token-based credentials for a reservation, it is necessary to perform a CIT at the time of reservation to be able perform a No-Show transaction later.

Example: A merchant submits a No-Show transaction because the cardholder did not follow cancellation policy for a reservation.

Merchant Y Optional





Industry Support for Incremental Authorizations

MCC Description 3351–3500 Car rental agencies 3501–3999 Lodging – hotels, motels, resorts 4111 Local and suburban commuter passenger transportation,

including ferries 4112 Passenger railways 4121 Taxicabs and limousines

Note: This will only be applicable for card-not-present transactions.

4131 Bus lines 4411 Steamship and cruise lines 4457 Boat rentals and leasing 5812 Eating places and restaurants 5813 Drinking places (alcoholic beverages)–bars, taverns,

nightclubs, cocktail lounges, and discotheques 7011 Lodging – hotels, motels, resorts, central reservations

services (not elsewhere classified) 7033 Trailer parks and campgrounds 7394 Equipment, tool, furniture, and appliance rental and

leasing 7512 Automobile rental agency 7513 Truck and utility trailer rentals 7519 Motor home and recreational vehicle rentals 7996 Amusement parks, circuses, carnivals, and fortune tellers 7999 Recreation services (not elsewhere classified)



APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS, (Continued) Real World Examples

Recurring (CREC and MREC) – New Relationship with Framework



APPENDIX AQ: CARDHOLDER INITIATED/MERCHANT INITIATED TRANSACTIONS, (Continued) Real World Examples, (Continued)

Recurring (CREC and MREC) – New Relationship with Framework, (Continued)




Recurring/Unscheduled Credential on File – Existing Relationship Outside of Framework




Recurring/Unscheduled Credential on File – Existing Relationship Outside of Framework, (Continued)




Incremental Example of incremental transactions for a hotel stay




Incremental, (Continued)




Reauthorization and Split Shipment Example of split shipment transactions for a merchandise order.




Reauthorization and Split Shipment, (Continued)





Message Type Records allow for the processing of cardholder initiated/merchant initiated transactions. Message Type Records are valid for ChaseNet and Visa transactions only. If a Message Type Record is sent but is not formatted properly, the transaction rejects with Response Reason Code 279 (Invalid MT Record Format). Refer to the Message Types Grid table in Appendix AQ: Cardholder and Merchant Initiated Transactions for additional information. Online Request:

1. Online Processing Detail Record a. Action Code =AR, AU, VF b. MOP = ChaseNet and Visa

2. Format indicator a. Message Type Records (MT)

i. Message Type Response:


a. Message Type Records (MT) Batch Request:


a. Action Code = AR, AU, DC, DP, VF

b. MOP = ChaseNet and Visa

2. Product Record

a. Message Type Records (PMT001)

i. Message Type

Response:


2. Product Record

a. Message Type Records (PMT001) Continued on next page




Appendix AM:Consumer Digital Payment Token


ChaseNet and Visa

All currencies





APPENDIX AR: ACCESS FX Cross Currency Introduction The ACCESS FX Cross Currency service allows a merchant to receive

custom Chase Corporate & Investment Bank (IB) foreign exchange rates that are used to process their cross currency transactions. The merchant receives rate sheets containing the currency pairs (source/destination) and rates that are enabled for processing the foreign exchange transactions. The rate file contains the negotiated rates for the merchant for each currency pair. Each rate includes a rate expiration date. The merchant selects rates that have expiration periods that can be used for both the Authorization and the Deposit. It is important that the merchant use the same Rate ID for both the Authorization and for the Deposit. If the Authorization Rate ID should expire before the Deposit is sent, another Rate ID must be selected and sent in for the Deposit transaction. The ACCESS FX Cross Currency transaction set (includes both sale and refund action codes) allows the merchant to communicate the desired IB exchange rates to be used for the transaction. The merchant sends the transaction with the Rate ID information in a new FX Product Record request to Merchant Services. In turn, Merchant Services sends the corresponding FX Product Record response as a notification of the status of the request and process with IB on the merchant’s behalf. The authorization and deposit transactions are independent of each other.

How It Works In order for the merchant to use the ACCESS FX Cross Currency service the

following is required: • Merchant must be enabled for Access FX Cross Currency at the

Merchant Division. • Method of Payment (MOP) must equal Visa, MasterCard or

International Maestro (EU only) • Merchant inbound specification formats must include either the Online

7.4 format or the 120 byte format: • Online 7.4 format: FX Cross Currency Format Indicator (FX) must

be sent with all Online FX transactions. • 120-byte format: Product Record: FX Cross Currency (PFX001)

must be sent for all batch FX Cross Currency transactions. • Mandatory: A merchant is required to send the mandatory FX Cross

Currency Format Indicator or FX Product Record; otherwise the transaction is rejected with Response Reason Code 227 - Missing Companion Data.

The merchant may choose to opt-out of ACCESS FX Cross Currency processing via the FX Product Record request. In the request, the Opt-out indicator is used to communicate the merchant’s choice for processing. If the Opt-out indicator is “Y”, the merchant is opting out and doesn’t want to use the custom IB rate. If the Opt-out indicator is “N” the merchant is opting in for the service and the IB custom rate processing applies.



APPENDIX AR: ACCESS FX Cross Currency, (Continued)


There are three types of transactions that are used in processing: Authorization, Deposit and Refund. The merchant sends the transaction request and receives a response for each transaction unless the merchant is not authorized for the service and a hard reject is returned by Merchant Services.

During the processing, if a Rate ID cannot be resolved, a default rate is used. The default rate is defined in the rate file on a per merchant basis. The default rate is used by Merchant Services when there is an issue with the Rate ID sent in by the merchant. For an authorization, Merchant Services uses default rate processing as the standard process. For the deposit or refund transactions, the merchant provides the Rate ID handling preference for processing. These preferences can either include using the default rate or rejecting the transaction. The Rate ID is considered to be invalid if it is expired, invalid or missing.

For the Authorization, the merchant looks up the Rate ID from the Rate File being used in the transaction. During the lookup process, the merchant selects a Rate ID based on the expiration date of the rate. If the authorization and anticipated deposit cannot be transmitted within the expiration timeframe, another Rate ID with a longer expiration period should be used. If the merchant chooses a Rate ID that expires before the deposit is made, Merchant Services processes the deposit transaction as a transaction with an expired Rate ID and uses default Rate ID processing.

For the Deposit, the merchant uses the Rate ID from the authorization request. If the merchant chooses a Rate ID that is expired before the deposit is made, Merchant Services processes the transaction with an expired Rate ID and uses the default Rate ID processing or rejects the transaction based on the merchant preference for deposit Rate ID handling process. If the transaction is rejected, the merchant must correct it and resend it with a valid Rate ID.

When a merchant sends a Refund transaction, they must select an "unexpired" Refund Rate ID from the rate sheet. If a single deposit transaction results in multiple refund transactions, each refund transaction must have an unexpired Rate ID for the transaction. For that reason, the Refund Rate ID’s used may be different for partial refunds.





The following Response Reason Codes may be generated during FX Cross Currency processing.

• 225 – Invalid Field Data - This reject is sent when the merchant is not authorized, Rate ID is invalid or Rate ID is missing. Unless the merchant is not authorized for FX Cross Currency, a response accompanies the error to provide further information on the reject reason.

• 227 – Missing Companion Data - This reject is used when the merchant is configured for FX Cross Currency, but has not sent in the mandatory FX Product Record or Online Format Indicator with the transaction.

• 238 – Invalid Currency – This reject is used when an invalid currency is sent in either the Presentment Currency field or the Settlement Currency field as part of the request.




The following transaction requirements define authorizations for ACCESS FX Rate transactions. Online Request:


a. Action Code = AU

b. MOP = IM, MC or VI


a. Access FX Cross Currency (FX)

Response:



a. Access FX Cross Currency (FX)

Batch Request:


a. Action Code = AU


2. Product Record

a. Access FX Cross Currency (PFX001)

Response:


2. Product Record




Transaction Types and Requirements (Continued)



a. Action Code = DP


2. Product Record


Response:


2. Product Record






Conditional Deposit deposits this transaction ONLY if a valid authorization is obtained. Batch Request:


a. Action Code = DC


2. Product Record


Response:


2. Product Record






Refund returns the amount to the accountholder’s account. Batch Request:


a. Action Code = RF


2. Product Record


Response:


2. Product Record




APPENDIX AR: ACCESS FX Cross Currency (Continued)

Card Types International Maestro, MasterCard and Visa

Supported Currencies

All currencies





End of Online Processing Format Specification © Chase 2017 – All rights reserved

Version 7.4 - Revision 12.4 11/12/2017

Documents

Technical - Magento 2€¦ · Technical Specification . Online Processing Format Specification . Version 7.4 – Revision 12.4 . November 12, 2017