eComm cnpAPI Reference Guide

May 2020
API Release: 12.13

Document Version: V2.18

Worldpay eComm cnpAPI Reference Guide - V2.18
All information whether text or graphics, contained in this manual is confidential and proprietary information of FIS and is provided to you solely
for the purpose of assisting you in using a FIS product. All such information is protected by copyright laws and international treaties. No part of
this manual may be reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise for any purpose without the
express written permission of FIS. The possession, viewing, or use of the information contained in this manual does not transfer any intellectual
property rights or grant a license to use this information or any software application referred to herein for any purpose other than that for which it
was provided. Information in this manual is presented "as is" and neither FIS or any other party assumes responsibility for typographical errors,
technical errors, or other inaccuracies contained in this document. This manual is subject to change without notice and does not represent a
commitment on the part FIS or any other party. FIS does not warrant that the information contained herein is accurate or complete.

Worldpay, the logo and any associated brand names are trademarks or registered trademarks of FIS and/or its affiliates in the US, UK or other
countries. All other trademarks are the property of their respective owners and all parties herein have consented to their trademarks appearing in
this manual. Any use by you of the trademarks included herein must have express written permission of the respective owner.
Copyright © 2003-2020, FIS and/or its affiliates - ALL RIGHTS RESERVED.
 CONTENTS
About This Guide
Intended Audience .................................................................................................................... xxiii
Revision History ........................................................................................................................ xxiii
Document Structure .................................................................................................................xxviii
Documentation Set ..................................................................................................................xxviii
Typographical Conventions ....................................................................................................... xxx
Contact Information................................................................................................................... xxxi

Chapter 1 Introduction
The cnpAPI Data Format .............................................................................................................. 2
Communications Protocols ..................................................................................................... 2
General XML Coding Requirements ....................................................................................... 3
Other XML Resources ............................................................................................................ 4
Batch Transaction Processing ...................................................................................................... 5
Recommended Session File Size ........................................................................................... 5
Multiple Daily Delivery............................................................................................................. 5
Payment Integration Platform (cnpAPI SDKs) .............................................................................. 7
Duplicate Transaction Detection ................................................................................................... 8
Batch Duplicate Checking....................................................................................................... 8
Batch Dupe Checking for Dynamic Payout Funding Instructions...................................... 9
Online Duplicate Checking...................................................................................................... 9
Coding for Report Groups........................................................................................................... 10
Additional/Alternate Methods of Tagging Transactions ....................................................... 11
Recovery..................................................................................................................................... 12
Authorization/Sale Recycling ................................................................................................ 12
Recycling Engine ........................................................................................................... 12
Account Updater Service ..................................................................................................... 14
Match Back ..................................................................................................................... 15
Merchant Requirements.................................................................................................. 16
Account Updater Features .............................................................................................. 17
Recurring Engine ....................................................................................................................... 18
Payment Plans...................................................................................................................... 18
Subscriptions ........................................................................................................................ 19
Add Ons and Discounts .................................................................................................. 21
Recurring Reports................................................................................................................. 21
Transaction Types and Uses ................................................................................................ 22
Issuer Insights............................................................................................................................. 24
Issuer Insights Secure Scheduled Report............................................................................. 24

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

iii
© 2020 FIS and/or its affiliates. All rights reserved.
 Real Time Indicators ............................................................................................................. 24
Prepaid Indicator ............................................................................................................. 24
Affluence Indicator .......................................................................................................... 25
Issuer Country Indicator .................................................................................................. 25
Cardholder Type Indicator............................................................................................... 26
Extended Network Data ........................................................................................................ 26
Insights Analytics Dashboard................................................................................................ 27
Fraud Toolkit .............................................................................................................................. 28
Essential Tier ........................................................................................................................ 29
Prepaid Card Filtering .................................................................................................... 29
International BIN Filtering ............................................................................................... 29
Prior Chargeback Filtering ............................................................................................. 30
Security Code No-Match Filter ....................................................................................... 30
Card Velocity Filtering .................................................................................................... 30
Prior Fraud Advice Filtering ............................................................................................ 31
AVS Filter ....................................................................................................................... 31
Email Velocity Filter......................................................................................................... 31
Phone Velocity Filter ....................................................................................................... 31
IP Velocity Filter .............................................................................................................. 32
Device Velocity Filter....................................................................................................... 32
Application of Filters - Filtering Rules ............................................................................. 32
Extended Tier........................................................................................................................ 33
Premium Tier ........................................................................................................................ 34
Modifications to Your Web Page........................................................................................... 34
cnpAPI Transactions ....................................................................................................... 34
Information Only Option .................................................................................................. 36
Fraud Check Transactions ............................................................................................. 36
Tokenization Feature .................................................................................................................. 38
How Tokenization Works ...................................................................................................... 39
Token Formats...................................................................................................................... 40
High Value Token Data Format Summary ...................................................................... 41
Low Value Token Summary ............................................................................................ 43
Obtaining Tokens.................................................................................................................. 44
Bulk Token Registration .................................................................................................. 44
Supported Token Transactions............................................................................................. 45
Compliance with Visa Best Practices for Tokenization ......................................................... 46
Direct Debit Processing .............................................................................................................. 47
Validation Feature................................................................................................................. 47
Verification Feature............................................................................................................... 47
Required Contents of Decline Notice .............................................................................. 47
Automatic Notice of Change (NoC) Updates ........................................................................ 48
Auto Redeposit Feature ........................................................................................................ 49
eCheck Prenotification .......................................................................................................... 49

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

iv
© 2020 FIS and/or its affiliates. All rights reserved.
eCommerce Solution for Apple Pay™ ........................................................................................ 51
Overview of Apple Pay Operation......................................................................................... 51
Worldpay Decryption of Apple Pay PKPaymentToken ......................................................... 51
Using the Browser JavaScript API for Apple Pay on the Web ........................................ 52
Using the Worldpay Mobile API for Apple Pay................................................................ 54
Submitting the Apple Pay PKPaymentToken in a cnpAPI Message............................... 55
Merchant Decryption of Apple Pay PKPaymentToken ......................................................... 56
Recurring Payments with Apple Pay..................................................................................... 57
eCommerce Solution for Google Pay™...................................................................................... 58
Branding Requirements ........................................................................................................ 58
Google Pay using eProtect ................................................................................................... 58
Merchant Decryption Method................................................................................................ 61
Recurring Payments with Google Pay .................................................................................. 63
Amazon Pay................................................................................................................................ 65
Healthcare Card Feature ............................................................................................................ 67
Supported Transaction Types..................................................................................................... 69
Authorization Transaction ..................................................................................................... 69
AVS Only Transaction..................................................................................................... 70
Authorization Reversal Transactions .................................................................................... 70
Notes on the Use of Authorization Reversal Transactions.............................................. 71
Using Authorization Reversal to Halt Recycling Engine.................................................. 71
Activate Transaction ............................................................................................................. 72
Activate Reversal Transaction (Online Only) ........................................................................ 72
Balance Inquiry Transaction ................................................................................................. 72
Cancel Subscription Transaction .......................................................................................... 72
Capture Transaction ............................................................................................................. 72
Capture Given Auth Transaction........................................................................................... 73
Create Plan Transaction ....................................................................................................... 73
Credit Transaction................................................................................................................. 73
Deactivate Transaction ......................................................................................................... 74
Deactivate Reversal Transaction (Online Only) .................................................................... 74
Deposit Reversal Transaction (Online Only)......................................................................... 74
eCheck Credit Transaction ................................................................................................... 74
eCheck Prenotification Credit Transaction............................................................................ 74
eCheck Prenotification Sale Transaction .............................................................................. 75
eCheck Redeposit Transaction............................................................................................. 75
eCheck Sales Transaction .................................................................................................... 75
eCheck Verification Transaction ........................................................................................... 75
eCheck Void Transaction (Online Only)................................................................................ 75
Force Capture Transaction ................................................................................................... 75
Gift Card Auth Reversal ........................................................................................................ 76
Gift Card Capture.................................................................................................................. 76
Gift Card Credit ..................................................................................................................... 76

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

v
© 2020 FIS and/or its affiliates. All rights reserved.
 Load Transaction .................................................................................................................. 76
Load Reversal Transaction (Online Only) ............................................................................. 76
Refund Reversal Transaction (Online Only) ......................................................................... 76
Register Token Transaction.................................................................................................. 76
Sale Transaction ................................................................................................................... 77
Status Query Transaction .................................................................................................... 77
Unload Transaction............................................................................................................... 77
Unload Reversal Transaction (Online Only) ......................................................................... 77
Update Card Validation Number Transaction ....................................................................... 78
Update Plan Transaction ...................................................................................................... 78
Update Subscription Transaction.......................................................................................... 78
Void Transaction (Online Only)............................................................................................. 78
Using Void to Halt Recycling Engine............................................................................... 78
Instruction-Based Dynamic Payout Transactions ................................................................ 79

Chapter 2 Testing Your cnpAPI Transactions

Certification and Testing Environments ...................................................................................... 82
Sandbox Environment........................................................................................................... 82
Pre-Live Environment ........................................................................................................... 82
Pre-Live Environment Limitations and Maintenance Schedules ..................................... 82
Overview of Testing .................................................................................................................... 84
Planning for Certification Testing .......................................................................................... 84
Required Certification Testing............................................................................................... 85
Optional Testing.................................................................................................................... 85
System Doctor ...................................................................................................................... 85
Transferring Files ........................................................................................................................ 88
Transferring Session Files .................................................................................................... 88
Submitting a Session File for Processing........................................................................ 88
Retrieving Processed Session Files................................................................................ 88
Transferring Online Files....................................................................................................... 89
ASP Programming Example ........................................................................................... 89
Java Programming Example ........................................................................................... 90
Notes on Timeout Settings.............................................................................................. 91
Notes on Persistent Connections.................................................................................... 92
Helpful Web Sites............................................................................................................ 92
Performing the Required Certification Tests ............................................................................... 93
Testing Authorization (including Indicators), AVS Only, Capture, Credit, Sale, and Void
Transactions ......................................................................................................................... 93
Testing Authorization Reversal Transactions ..................................................................... 106
Testing Direct Debit Transactions ....................................................................................... 110
Testing Token Transactions................................................................................................ 117
Testing Query Transactions ................................................................................................ 121
Testing Stored Credentials Processing............................................................................... 122

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

vi
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Online Duplicate Transaction Processing .............................................................. 125
Testing Refund Authorization.............................................................................................. 126
Performing the Optional Tests .................................................................................................. 128
Testing AVS and Card Validation ....................................................................................... 129
Testing Address Responses ............................................................................................... 130
Testing Advanced AVS Response Codes .......................................................................... 132
Testing Response Reason Codes and Messages .............................................................. 133
Testing 3DS Responses ..................................................................................................... 136
Testing the Prepaid Filtering Feature.................................................................................. 138
Testing the International Card Filter Feature ...................................................................... 139
Testing Security Code No-Match Filtering .......................................................................... 141
Testing Advanced Fraud Tools ........................................................................................... 142
Testing Account Updater .................................................................................................... 144
Testing Account Updater Extended Response Codes.................................................. 145
Testing Account Updater for Tokenized Merchants ...................................................... 146
Testing Tax Billing............................................................................................................... 146
Testing Convenience Fees ................................................................................................. 147
Testing the Recycling Engine ............................................................................................. 149
Testing Recycling Engine Cancellation......................................................................... 157
Testing Recurring Engine Transactions .............................................................................. 159
Testing Gift Card Transactions ........................................................................................... 171
Testing MasterPass Transactions....................................................................................... 180
Testing Apple Pay Transaction Processing ........................................................................ 181
Testing the Submission of the Decrypted PKPaymentToken in cnpAPI ....................... 181
Testing the Submission of PKPaymentToken in cnpAPI .............................................. 182
Testing Google Pay Transaction Processing...................................................................... 183
Testing Google Pay using eProtect............................................................................... 183
Testing Amazon Pay........................................................................................................... 184
Testing checkoutId.............................................................................................................. 187
Testing Encrypted Card and CVV in Register Token Requests ......................................... 188
Testing Transaction Volume Capacity ................................................................................ 189

Chapter 3 cnpAPI Transaction Examples

Overview of Online and Batch Processing Formats ................................................................. 192
Batch Process Format ........................................................................................................ 192
Supported Communication Protocols............................................................................ 193
Batch Processing Request Format ............................................................................... 193
Batch Processing Response Format............................................................................. 193
Online Processing Format ........................................................................................................ 194
Supported Communication Protocols ................................................................................. 195
Online Processing Request Format .................................................................................... 195
Online Processing Response Format ................................................................................. 195
Transaction Types and Examples............................................................................................. 196

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

vii
© 2020 FIS and/or its affiliates. All rights reserved.
 Authorization Transactions ................................................................................................. 198
Authorization Request Structure ................................................................................... 198
Authorization Response Structure ................................................................................ 205
Authorization Reversal Transactions .................................................................................. 210
Authorization Reversal Requests.................................................................................. 210
Authorization Reversal Responses ............................................................................... 211
Activate Transactions.......................................................................................................... 212
Activate Request ........................................................................................................... 212
Activate Response ........................................................................................................ 214
Activate Reversal Transactions (Online Only) .................................................................... 215
Activate Reversal Request............................................................................................ 215
Activate Reversal Response ......................................................................................... 216
Balance Inquiry Transactions.............................................................................................. 217
Balance Inquiry Request ............................................................................................... 217
Balance Inquiry Response ............................................................................................ 218
Cancel Subscription Transactions ...................................................................................... 219
Cancel Subscription Request........................................................................................ 219
Cancel Subscription Response ..................................................................................... 219
Capture Transactions.......................................................................................................... 220
Capture Request ........................................................................................................... 220
Capture Response ........................................................................................................ 227
Capture Given Auth Transactions ....................................................................................... 228
Capture Given Auth Request ........................................................................................ 228
Capture Given Auth Response ..................................................................................... 232
Create Plan Transactions ................................................................................................... 234
Create Plan Request..................................................................................................... 234
Create Plan Response .................................................................................................. 235
Credit Transactions............................................................................................................. 235
Credit Request for a Worldpay Processed Transaction ................................................ 236
Credit Request for a Non-Worldpay Processed Transaction ........................................ 240
Credit Response ........................................................................................................... 244
Deactivate Transactions ..................................................................................................... 245
Deactivate Request....................................................................................................... 245
Deactivate Response .................................................................................................... 246
Deactivate Reversal Transactions (Online Only) ................................................................ 247
Deactivate Reversal Request........................................................................................ 247
Deactivate Reversal Response..................................................................................... 248
Deposit Reversal Transactions (Online Only) ..................................................................... 249
Deposit Reversal Request ............................................................................................ 249
Deposit Reversal Response.......................................................................................... 250
eCheck Credit Transactions................................................................................................ 251
eCheck Credit Request Against a Worldpay Transaction ............................................. 251
eCheck Credit Request for a Non-Worldpay Processed Sale....................................... 253

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

viii
© 2020 FIS and/or its affiliates. All rights reserved.
 eCheck Credit Response .............................................................................................. 253
eCheck Prenotification Credit Transactions (Batch Only) ................................................... 254
eCheck Prenotification Credit Request ......................................................................... 254
eCheck Prenotification Credit Response ...................................................................... 255
eCheck Prenotification Sale Transactions (Batch Only) ..................................................... 256
eCheck Prenotification Sale Request............................................................................ 256
eCheck Prenotification Sale Response......................................................................... 257
eCheck Redeposit Transactions ......................................................................................... 258
eCheck Redeposit Request .......................................................................................... 258
eCheck Redeposit Response........................................................................................ 260
eCheck Sale Transactions .................................................................................................. 261
eCheck Sale Request ................................................................................................... 261
eCheck Sale Response................................................................................................. 263
eCheck Verification Transactions ....................................................................................... 264
eCheck Verification Request......................................................................................... 264
eCheck Verification Response ...................................................................................... 267
eCheck Void Transactions (Online Only) ............................................................................ 268
eCheck Void Request ................................................................................................... 268
eCheck Void Response................................................................................................. 269
Force Capture Transactions ............................................................................................... 269
Force Capture Request................................................................................................. 269
Force Capture Response .............................................................................................. 273
Fraud Check Transaction.................................................................................................... 274
Fraud Check Request ................................................................................................... 274
Fraud Check Response ................................................................................................ 276
Gift Card Auth Reversal Transactions ................................................................................ 276
Gift Card Auth Reversal Request.................................................................................. 276
Gift Card Auth Reversal Response ............................................................................... 277
Gift Card Capture Transactions .......................................................................................... 278
Gift Card Capture Request............................................................................................ 278
Gift Card Capture Response......................................................................................... 279
Gift Card Credit Transactions ............................................................................................. 280
Gift Card Credit Request............................................................................................... 280
Gift Card Credit Response ............................................................................................ 282
Load Transactions .............................................................................................................. 282
Load Request................................................................................................................ 283
Load Response ............................................................................................................. 283
Load Reversal Transactions (Online Only) ......................................................................... 284
Load Reversal Request................................................................................................. 285
Load Reversal Response.............................................................................................. 285
Status Query Transactions (Online Only) .......................................................................... 286
Query Transaction Request .......................................................................................... 287
Query Transaction Response ....................................................................................... 287

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

ix
© 2020 FIS and/or its affiliates. All rights reserved.
 Refund Reversal Transactions (Online Only) ..................................................................... 290
Refund Reversal Request ............................................................................................. 290
Refund Reversal Response .......................................................................................... 291
Register Token Transactions .............................................................................................. 292
Register Token Request ............................................................................................... 292
Register Token Response............................................................................................. 296
RFR Transactions (Batch Only) .......................................................................................... 299
RFR Request ................................................................................................................ 299
RFR Response.............................................................................................................. 300
Sale Transactions ............................................................................................................... 300
Sale Request................................................................................................................. 300
Sale Response.............................................................................................................. 304
Translate to Low Value Token Transaction ........................................................................ 310
Translate to Low Value Token Request ........................................................................ 310
Translate to Low Value Token Response ..................................................................... 310
Unload Transactions ........................................................................................................... 311
Unload Request ............................................................................................................ 311
Unload Response.......................................................................................................... 312
Unload Reversal Transactions (Online Only)...................................................................... 312
Unload Reversal Request ............................................................................................. 313
Unload Reversal Response .......................................................................................... 314
Update Plan Transactions................................................................................................... 314
Update Plan Request .................................................................................................... 315
Update Plan Response ................................................................................................. 315
Update Subscription Transactions ...................................................................................... 316
Update Subscription Request ....................................................................................... 316
Update Subscription Response..................................................................................... 317
Update Card Validation Number Transactions ................................................................... 318
Update Card Validation Number Request..................................................................... 318
Update Card Validation Number Response .................................................................. 319
Void Transactions (Online Only) ......................................................................................... 319
Void Request................................................................................................................. 320
Void Response.............................................................................................................. 321

Chapter 4 cnpAPI Elements

accNum .................................................................................................................................... 324
accountInfo .............................................................................................................................. 325
accountInformation .................................................................................................................. 326
accountLogin............................................................................................................................. 327
accountNumber ........................................................................................................................ 328
accountNumberLength ............................................................................................................. 329
accountPasshash ..................................................................................................................... 330
accountRangeId ....................................................................................................................... 331

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

x
© 2020 FIS and/or its affiliates. All rights reserved.
accountUpdate ......................................................................................................................... 332
accountUpdateFileRequestData .............................................................................................. 333
accountUpdater ........................................................................................................................ 334
accountUpdateResponse ......................................................................................................... 338
accountUpdateSource ............................................................................................................. 339
accType .................................................................................................................................... 340
actionReason ........................................................................................................................... 341
activate ..................................................................................................................................... 342
activateResponse .................................................................................................................... 343
activateReversal ...................................................................................................................... 344
activateReversalResponse ...................................................................................................... 345
active ........................................................................................................................................ 346
addOnCode .............................................................................................................................. 347
addressLine1, addressLine2, addressLine3 ............................................................................. 348
advancedAVSResult ................................................................................................................. 349
advancedFraudChecks ............................................................................................................ 350
advancedFraudResults ............................................................................................................ 351
affiliate....................................................................................................................................... 352
affluence ................................................................................................................................... 353
allowPartialAuth ........................................................................................................................ 354
amount ...................................................................................................................................... 355
androidpayResponse ............................................................................................................... 356
applepay ................................................................................................................................... 357
applepayResponse ................................................................................................................... 358
applicationData ......................................................................................................................... 359
applicationExpirationDate ......................................................................................................... 360
applicationPrimaryAccountNumber........................................................................................... 361
approvedAmount....................................................................................................................... 362
authAmount............................................................................................................................... 363
authCode .................................................................................................................................. 364
authDate ................................................................................................................................... 365
authenticatedByMerchant ......................................................................................................... 366
authentication............................................................................................................................ 367
authenticationProtocolVersion .................................................................................................. 368
authenticationResult ................................................................................................................. 369
authenticationTransactionId...................................................................................................... 370
authenticationValue .................................................................................................................. 371
authInformation ......................................................................................................................... 372
authorization ............................................................................................................................. 373
authorizationResponse ............................................................................................................. 374
authReversal............................................................................................................................. 375
authReversalResponse............................................................................................................. 376
availableBalance....................................................................................................................... 377

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xi
© 2020 FIS and/or its affiliates. All rights reserved.
 avsResult .................................................................................................................................. 378
balanceInquiry .......................................................................................................................... 379
balanceInquiryResponse ......................................................................................................... 380
batchRequest............................................................................................................................ 381
batchResponse ......................................................................................................................... 390
beginningBalance .................................................................................................................... 391
billingDate ................................................................................................................................ 392
billToAddress ............................................................................................................................ 393
bin ............................................................................................................................................. 395
bypassVelocityCheck................................................................................................................ 396
campaign .................................................................................................................................. 397
cancelSubscription ................................................................................................................... 398
cancelSubscriptionResponse ................................................................................................... 399
capability ................................................................................................................................... 400
capture ...................................................................................................................................... 401
captureAmount.......................................................................................................................... 402
captureGivenAuth ..................................................................................................................... 403
captureGivenAuthResponse ..................................................................................................... 404
captureResponse...................................................................................................................... 405
card ........................................................................................................................................... 406
cardAcceptorTaxId.................................................................................................................... 408
cardholderAuthentication .......................................................................................................... 409
cardholderId .............................................................................................................................. 410
cardholderName ....................................................................................................................... 411
cardOrToken ............................................................................................................................. 412
cardProductType....................................................................................................................... 413
cardSuffix ................................................................................................................................. 414
cardValidationNum.................................................................................................................... 415
cardValidationResult ................................................................................................................. 416
cashBackAmount ..................................................................................................................... 417
catLevel .................................................................................................................................... 418
ccdPaymentInformation ........................................................................................................... 419
chargeback ............................................................................................................................... 420
checkInDate .............................................................................................................................. 421
checkNum ................................................................................................................................ 422
checkOutDate ........................................................................................................................... 423
checkoutId ................................................................................................................................ 424
city............................................................................................................................................. 425
clinicOtherAmount..................................................................................................................... 426
cnpInternalRecurringRequest .................................................................................................. 427
cnpOnlineRequest .................................................................................................................... 428
cnpOnlineResponse ................................................................................................................. 429
cnpRequest............................................................................................................................... 431

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xii
© 2020 FIS and/or its affiliates. All rights reserved.
cnpResponse ............................................................................................................................ 432
cnpSessionId ............................................................................................................................ 433
cnpToken .................................................................................................................................. 434
cnpTxnId ................................................................................................................................... 435
code .......................................................................................................................................... 436
commodityCode ........................................................................................................................ 437
companyName.......................................................................................................................... 438
country ...................................................................................................................................... 439
createAddOn ............................................................................................................................ 440
createDiscount ......................................................................................................................... 441
createPlan ................................................................................................................................ 442
createPlanResponse ................................................................................................................ 443
credit ......................................................................................................................................... 444
creditAmount............................................................................................................................. 445
creditCnpTxnId ......................................................................................................................... 446
creditResponse ......................................................................................................................... 447
cryptogram ............................................................................................................................... 448
currencyCode ........................................................................................................................... 449
customAttribute1 ...................................................................................................................... 450
customBilling............................................................................................................................. 451
customIdentifier ........................................................................................................................ 453
customerCredit ......................................................................................................................... 454
customerCreditResponse ........................................................................................................ 455
customerDebit .......................................................................................................................... 456
customerDebitResponse .......................................................................................................... 457
customerInfo ............................................................................................................................. 458
customerIpAddress ................................................................................................................... 459
customerName.......................................................................................................................... 460
customerReference................................................................................................................... 461
customerRegistrationDate ........................................................................................................ 462
customerServicePhone............................................................................................................. 463
customerType ........................................................................................................................... 464
customerWorkTelephone ......................................................................................................... 465
ctxPaymentDetail ..................................................................................................................... 466
ctxPaymentInformation ............................................................................................................ 467
data ........................................................................................................................................... 468
deactivate ................................................................................................................................. 469
deactivateResponse ................................................................................................................ 470
deactivateReversal .................................................................................................................. 471
deactivateReversalResponse .................................................................................................. 472
debitNetworkName .................................................................................................................. 473
debtRepayment......................................................................................................................... 474
deleteAddOn ............................................................................................................................ 475

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xiii
© 2020 FIS and/or its affiliates. All rights reserved.
 deleteDiscount ......................................................................................................................... 476
deliveryType.............................................................................................................................. 477
dentalAmount............................................................................................................................ 478
depositReversal ....................................................................................................................... 479
depositReversalResponse ....................................................................................................... 480
description ................................................................................................................................ 481
descriptor .................................................................................................................................. 482
destinationCountryCode ........................................................................................................... 483
destinationPostalCode .............................................................................................................. 484
detailTax ................................................................................................................................... 485
deviceManufacturerIdentifier..................................................................................................... 486
deviceReputationScore ............................................................................................................ 487
deviceReviewStatus.................................................................................................................. 488
disbursementType ................................................................................................................... 489
discountAmount ........................................................................................................................ 491
discountCode ........................................................................................................................... 492
dob ............................................................................................................................................ 493
duration ..................................................................................................................................... 494
dutyAmount............................................................................................................................... 495
echeck....................................................................................................................................... 496
eCheckAccountSuffix ............................................................................................................... 497
echeckCredit ............................................................................................................................. 498
echeckCreditResponse............................................................................................................. 499
echeckForToken ....................................................................................................................... 500
echeckPreNoteCredit ............................................................................................................... 501
echeckPreNoteCreditResponse ............................................................................................... 502
echeckPreNoteSale ................................................................................................................. 503
echeckPreNoteSaleResponse ................................................................................................. 504
echeckRedeposit ...................................................................................................................... 505
echeckRedepositResponse ...................................................................................................... 506
echeckSale ............................................................................................................................... 507
echeckSalesResponse ............................................................................................................. 508
echeckToken............................................................................................................................. 509
echeckVerification..................................................................................................................... 510
echeckVerificationResponse..................................................................................................... 511
echeckVoid ............................................................................................................................... 512
echeckVoidResponse ............................................................................................................... 513
eciIndicator................................................................................................................................ 514
email ......................................................................................................................................... 515
employerName.......................................................................................................................... 516
encryptedAccountNumber ....................................................................................................... 517
encryptedCardValidationNum .................................................................................................. 518
encryptedTrack ........................................................................................................................ 519

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xiv
© 2020 FIS and/or its affiliates. All rights reserved.
encryptionKeyId ....................................................................................................................... 520
Obtaining a Public Encryption Key...................................................................................... 520
endDate ................................................................................................................................... 521
endingBalance ......................................................................................................................... 522
endpoint ................................................................................................................................... 523
enhancedAuthResponse........................................................................................................... 524
enhancedData........................................................................................................................... 526
entryMode ................................................................................................................................. 530
ephemeralPublicKey ................................................................................................................. 531
eventType ................................................................................................................................. 532
expDate..................................................................................................................................... 533
expMonth ................................................................................................................................. 534
expYear .................................................................................................................................... 535
extendedCardResponse .......................................................................................................... 536
fastAccessFunding ................................................................................................................... 537
fastAccessFundingResponse .................................................................................................. 538
fieldValue ................................................................................................................................. 539
filtering ...................................................................................................................................... 540
finalPayment ............................................................................................................................ 541
fireSafetyIndicator ..................................................................................................................... 542
firstName................................................................................................................................... 543
forceCapture ............................................................................................................................. 544
forceCaptureResponse ............................................................................................................. 545
formatId .................................................................................................................................... 546
fraudCheck ............................................................................................................................... 547
fraudCheckResponse .............................................................................................................. 548
fraudFilterOverride ................................................................................................................... 549
fraudResult ............................................................................................................................... 550
fundingCustomerId.................................................................................................................... 551
fundingInstructionVoid ............................................................................................................. 552
fundingInstructionVoidResponse ............................................................................................. 553
fundingSource........................................................................................................................... 554
fundingSubmerchantId ............................................................................................................. 555
fundsTransferId......................................................................................................................... 556
giftCardAuthReversal................................................................................................................ 557
giftCardAuthReversalResponse................................................................................................ 558
giftCardBin ............................................................................................................................... 559
giftCardCapture......................................................................................................................... 560
giftCardCaptureResponse ........................................................................................................ 561
giftCardCredit............................................................................................................................ 562
giftCardCreditResponse............................................................................................................ 563
giftCardResponse .................................................................................................................... 564
giropay ...................................................................................................................................... 565

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xv
© 2020 FIS and/or its affiliates. All rights reserved.
 giropayResponse ...................................................................................................................... 566
header ...................................................................................................................................... 567
healthcareAmounts ................................................................................................................... 568
healthcareIIAS .......................................................................................................................... 569
hotelFolioNumber...................................................................................................................... 570
iban .......................................................................................................................................... 571
ideal .......................................................................................................................................... 572
idealResponse .......................................................................................................................... 573
IIASFlag .................................................................................................................................... 574
incomeAmount .......................................................................................................................... 575
incomeCurrency........................................................................................................................ 576
international .............................................................................................................................. 577
intervalType ............................................................................................................................. 578
invoiceReferenceNumber ......................................................................................................... 579
issuerCountry............................................................................................................................ 580
itemDescription ......................................................................................................................... 581
itemDiscountAmount................................................................................................................. 582
itemSequenceNumber .............................................................................................................. 583
ksn ............................................................................................................................................ 584
lastName................................................................................................................................... 585
lineItemData.............................................................................................................................. 586
lineItemTotal ............................................................................................................................. 588
lineItemTotalWithTax ................................................................................................................ 589
load .......................................................................................................................................... 590
loadResponse .......................................................................................................................... 591
loadReversal ............................................................................................................................ 592
loadReversalResponse ............................................................................................................ 593
location...................................................................................................................................... 594
lodgingCharge........................................................................................................................... 595
lodgingInfo ................................................................................................................................ 596
mandateProvider ...................................................................................................................... 598
mandateReference .................................................................................................................. 599
mandateSignatureDate ............................................................................................................ 600
mandateURL ............................................................................................................................ 601
matchCount............................................................................................................................... 602
merchantCategoryCode............................................................................................................ 603
merchantData ........................................................................................................................... 604
merchantGroupingId ................................................................................................................. 605
merchantId ................................................................................................................................ 606
message ................................................................................................................................... 607
middleInitial ............................................................................................................................... 608
mpos ......................................................................................................................................... 609
name ......................................................................................................................................... 610

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xvi
© 2020 FIS and/or its affiliates. All rights reserved.
 name as a child of lodgingCharge ...................................................................................... 610
networkField ............................................................................................................................. 612
networkName ........................................................................................................................... 614
networkResponse .................................................................................................................... 615
networkSubField ...................................................................................................................... 616
networkTransactionId ............................................................................................................... 617
newAccountInfo ........................................................................................................................ 618
newCardInfo ............................................................................................................................. 619
newCardTokenInfo ................................................................................................................... 620
newTokenInfo ........................................................................................................................... 621
nextRecycleTime ..................................................................................................................... 622
numAdults ................................................................................................................................. 623
number...................................................................................................................................... 624
numberOfPayments ................................................................................................................. 625
onlinePaymentCryptogram ....................................................................................................... 626
orderDate .................................................................................................................................. 627
orderId....................................................................................................................................... 628
orderSource .............................................................................................................................. 629
originalAccountInfo ................................................................................................................... 631
origAccountNumber ................................................................................................................. 632
origActionType ......................................................................................................................... 633
origCnpTxnId ........................................................................................................................... 634
origId ........................................................................................................................................ 635
originalAmount .......................................................................................................................... 636
originalCard............................................................................................................................... 637
originalCardInfo ........................................................................................................................ 638
originalCardTokenInfo .............................................................................................................. 639
originalNetworkTransactionId .................................................................................................. 640
Stored Credentials - After the Initial Transaction ................................................................ 640
originalRefCode ........................................................................................................................ 641
originalSequenceNumber ......................................................................................................... 642
originalSystemTraceId .............................................................................................................. 643
originalToken ........................................................................................................................... 644
originalTokenInfo ..................................................................................................................... 645
originalTransactionAmount ...................................................................................................... 646
originalTxnTime ........................................................................................................................ 647
password .................................................................................................................................. 648
payerId ..................................................................................................................................... 649
payFacCredit ............................................................................................................................ 650
payFacCreditResponse ........................................................................................................... 651
payFacDebit ............................................................................................................................. 652
payFacDebitResponse ............................................................................................................. 653
paymentAccountReferenceNumber ......................................................................................... 654

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xvii
© 2020 FIS and/or its affiliates. All rights reserved.
 paymentDataType .................................................................................................................... 655
paymentPurpose....................................................................................................................... 656
payoutOrgCredit ....................................................................................................................... 657
payoutOrgCerditResponse ...................................................................................................... 658
payoutOrgDebit ........................................................................................................................ 659
payoutOrgDebitResponse ........................................................................................................ 660
paypage .................................................................................................................................... 661
paypageRegistrationId .............................................................................................................. 662
paypal ....................................................................................................................................... 663
payPalNotes ............................................................................................................................. 664
payPalOrderComplete .............................................................................................................. 665
phone ........................................................................................................................................ 666
phone as a child of billToAddress and shipToAddress ................................................. 666
phone as a child of customBilling.................................................................................. 666
physicalCheckCredit ................................................................................................................ 667
physicalCheckCreditResponse ................................................................................................ 668
physicalCheckDebit .................................................................................................................. 669
physicalCheckDebitResponse ................................................................................................. 670
pin ............................................................................................................................................ 671
pinlessDebitRequest ................................................................................................................ 672
pinlessDebitResponse ............................................................................................................. 673
planCode .................................................................................................................................. 674
pos ............................................................................................................................................ 675
postDate.................................................................................................................................... 676
postDay .................................................................................................................................... 677
preferredDebitNetworks ............................................................................................................ 678
preferredLanguage .................................................................................................................. 679
prepaid ...................................................................................................................................... 680
prepaidCardType ...................................................................................................................... 681
processingInstructions .............................................................................................................. 682
processingType ........................................................................................................................ 683
Stored Credentials - After the Initial Transaction ................................................................ 683
productCode ............................................................................................................................. 685
programCode ............................................................................................................................ 686
propertyLocalPhone.................................................................................................................. 687
publicKeyHash ......................................................................................................................... 688
quantity ..................................................................................................................................... 689
queryTransaction ..................................................................................................................... 690
queryTransactionResponse ..................................................................................................... 691
queryTransactionUnavailableResponse .................................................................................. 692
recurringRequest ..................................................................................................................... 693
recurringResponse ................................................................................................................... 694
recurringTxnId .......................................................................................................................... 695

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xvii
© 2020 FIS and/or its affiliates. All rights reserved.
recycleAdvice............................................................................................................................ 696
recycleAdviceEnd .................................................................................................................... 697
recycleBy .................................................................................................................................. 698
recycleEngineActive ................................................................................................................. 699
recycleId ................................................................................................................................... 700
recyclingResponse ................................................................................................................... 701
recyclingResponse Element as a Child of authorizationResponse or saleResponse......... 701
recyclingResponse Element as a Child of voidResponse................................................... 701
recyclingRequest ...................................................................................................................... 703
redirectToken ........................................................................................................................... 704
redirectUrl ................................................................................................................................ 705
refCode ..................................................................................................................................... 706
refundReversal ......................................................................................................................... 707
refundReversalResponse ........................................................................................................ 708
registerTokenRequest............................................................................................................... 709
registerTokenResponse............................................................................................................ 710
reloadable ................................................................................................................................. 711
reserveCredit ........................................................................................................................... 712
reserveCreditResponse ........................................................................................................... 713
reserveDebit ............................................................................................................................. 714
reserveDebitResponse ............................................................................................................. 715
residenceStatus ........................................................................................................................ 716
response ................................................................................................................................... 717
responseCode .......................................................................................................................... 718
responseMessage .................................................................................................................... 719
responseTime ........................................................................................................................... 720
results_Max10 .......................................................................................................................... 721
RFRRequest ............................................................................................................................. 724
RFRResponse .......................................................................................................................... 725
roomRate .................................................................................................................................. 726
roomTax.................................................................................................................................... 727
routingNum .............................................................................................................................. 728
routingPreference .................................................................................................................... 729
RxAmount ................................................................................................................................. 730
sale ........................................................................................................................................... 731
saleResponse ........................................................................................................................... 732
salesTax.................................................................................................................................... 733
secondaryAmount .................................................................................................................... 734
sepaDirectDebit ....................................................................................................................... 735
sepaDirectDebitResponse ....................................................................................................... 736
sequenceNumber...................................................................................................................... 737
sequenceType ......................................................................................................................... 738
shipFromPostalCode ................................................................................................................ 739

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xix
© 2020 FIS and/or its affiliates. All rights reserved.
 shippingAmount ........................................................................................................................ 740
shipToAddress .......................................................................................................................... 741
showStatusOnly ........................................................................................................................ 742
signature ................................................................................................................................... 743
skipRealtimeAU ....................................................................................................................... 744
sofort ......................................................................................................................................... 745
sofortResponse......................................................................................................................... 746
ssn ........................................................................................................................................... 747
startDate .................................................................................................................................. 748
state .......................................................................................................................................... 749
submerchantCredit ................................................................................................................... 750
submerchantCreditResponse .................................................................................................. 751
submerchantDebit .................................................................................................................... 752
submerchantDebitResponse .................................................................................................... 753
submerchantName.................................................................................................................... 754
subscription .............................................................................................................................. 755
subscriptionId ........................................................................................................................... 757
surchargeAmount ..................................................................................................................... 758
systemTraceId .......................................................................................................................... 759
taxAmount................................................................................................................................. 760
taxExempt ................................................................................................................................. 761
taxIncludedInTotal..................................................................................................................... 762
taxRate...................................................................................................................................... 763
taxType ..................................................................................................................................... 764
taxTypeIdentifier ....................................................................................................................... 765
terminalId ................................................................................................................................. 766
threatMetrixSessionId .............................................................................................................. 767
token ......................................................................................................................................... 768
token (structure for card replacement)................................................................................ 768
token (PayPal generated) ................................................................................................... 769
token (for conversion to LVT).............................................................................................. 769
tokenMessage........................................................................................................................... 770
tokenResponse ......................................................................................................................... 771
tokenResponseCode ................................................................................................................ 772
tokenUrl..................................................................................................................................... 773
totalHealthcareAmount ............................................................................................................ 774
track .......................................................................................................................................... 775
track1Status ............................................................................................................................. 776
track2Status ............................................................................................................................. 777
transactionAmount ................................................................................................................... 778
transactionId ............................................................................................................................. 779
transactionId as a Child of the paypal element ................................................................... 779
transactionId as a Child of the header element .................................................................. 779

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xx
© 2020 FIS and/or its affiliates. All rights reserved.
translateToLowValueTokenRequest ........................................................................................ 780
translateToLowValueTokenResponse ..................................................................................... 781
trialIntervalType ....................................................................................................................... 782
trialNumberOfIntervals ............................................................................................................. 783
triggeredRule ........................................................................................................................... 784
txnTime ..................................................................................................................................... 785
type ........................................................................................................................................... 786
type Element as a Child of the parent elements listed below ............................................. 786
type Element as a Child of fundingSource.......................................................................... 787
unitCost..................................................................................................................................... 788
unitOfMeasure .......................................................................................................................... 789
unload ...................................................................................................................................... 790
unloadResponse ...................................................................................................................... 791
unloadReversal ........................................................................................................................ 792
unloadReversalResponse ........................................................................................................ 793
updateAddOn ........................................................................................................................... 794
updatedCard ............................................................................................................................. 795
updateCardValidationNumOnToken ......................................................................................... 796
updateCardValidationNumOnTokenResponse......................................................................... 797
updateDiscount ........................................................................................................................ 798
updatePlan ............................................................................................................................... 799
updatePlanResponse ............................................................................................................... 800
updateSubscription .................................................................................................................. 801
updateSubscriptionResponse .................................................................................................. 805
updatedToken ........................................................................................................................... 806
url .............................................................................................................................................. 807
user ........................................................................................................................................... 808
vendorCredit ............................................................................................................................ 809
vendorCreditResponse ............................................................................................................ 810
vendorDebit .............................................................................................................................. 811
vendorDebitResponse ............................................................................................................. 812
vendorName ............................................................................................................................ 813
verificationCode ........................................................................................................................ 814
verify ......................................................................................................................................... 815
version ..................................................................................................................................... 816
virtualAccountNumber .............................................................................................................. 817
virtualGiftCard .......................................................................................................................... 818
virtualGiftCardBin ..................................................................................................................... 819
virtualGiftCardResponse .......................................................................................................... 820
visionAmount ............................................................................................................................ 821
void ........................................................................................................................................... 822
voidResponse ........................................................................................................................... 823
wallet ........................................................................................................................................ 824

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxi
© 2020 FIS and/or its affiliates. All rights reserved.
 walletSourceType .................................................................................................................... 825
walletSourceTypeId ................................................................................................................. 826
webSessionId............................................................................................................................ 827
yearsAtEmployer....................................................................................................................... 828
yearsAtResidence..................................................................................................................... 829
zip ............................................................................................................................................. 830

Appendix A Payment Transaction Response Codes

Payment Transaction Response Codes ................................................................................... 832
3DS Authentication Result Codes............................................................................................. 857
AVS Response Codes .............................................................................................................. 859
AAVS Response Codes............................................................................................................ 860
Card Validation Response Codes............................................................................................. 863
Advanced Fraud Tools Triggered Rules ................................................................................... 864
XML Validation Error Messages ............................................................................................... 880
Additional Response Header Error Messages.......................................................................... 882
ACH Return Reason Codes...................................................................................................... 884
ACH NoC Change Codes ......................................................................................................... 887
Canadian EFT Return Codes.................................................................................................... 888

Appendix B Credit Card Number Formats

Appendix C Test Card Numbers

Appendix D PayFac Dynamic Payout

Advantages of Using Dynamic Payout...................................................................................... 900
Overview of Dynamic Payout ................................................................................................... 901
Timing of Transactions, Reports, and Money Movement ................................................... 902
Money Movement and Accounts ........................................................................................ 903
Same Day Funding ...................................................................................................... 905
FastAccess Funding ..................................................................................................... 905
Account Balance Verifications....................................................................................... 906
Examples of Funding Instructions ............................................................................................ 908
Funding Instruction Void Transactions................................................................................ 914
Funding Instruction Certification Testing................................................................................... 915
SSR Reports ............................................................................................................................. 918
Tax ID Validation Process ........................................................................................................ 920

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxii
© 2020 FIS and/or its affiliates. All rights reserved.
About This Guide

This manual serves as a reference to the cnpAPI transaction formats used for payment processing with
FIS. It also explains how to perform unattended transaction testing and attended certification testing with
Worldpay.

Intended Audience
This document is intended for technical personnel who set-up and maintaining payment processing using
the cnpAPI format.

Revision History
The revision history of this document is as follows:

TABLE 1 Document Revision History

Doc.
Version Description Location(s)

2.18 Changed Chargeback Group contact info. About this Guide

Added name to echeckSale and echeckCredit tests. Chapter 2
Removed secondaryAmount from capture transaction. It was Chapter 4
listed in error.

2.17 Changed the location attribute to an element and added it to all Chapters 3 and 4
transaction type response messages.
Removed the "Not generally available..." Note from the Chapter 4
lodgingInfo element and 12 child elements.
Changed Same Day Funding daily limit from $25,000 to $100, 000. Appendix D

2.16 Removed 001 response code from Auth Reversal example Chapter 3

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxiii
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

TABLE 1 Document Revision History

Doc.
Version Description Location(s)

2.15 Added Response Codes 980 and 651 through 670. Appendix A
Clarified note in test 43. Chapter 2
Removed test 60. Chapter 2

2.14 Added info about the new location attribute for Online responses. Chapters 3 and 4
Added a Table for subsequent transactions in a Stored Credentials Chapter 4
stream to multiple element pages.
Added Note about stripping/padding to accNum and routingNum. Chapter 4
Added Note about Mastercard 3DS Result Codes. Also, added info Appendix A
about Response Codes 945 and 046.

2.13 Removed reference to FTP with PGP encryption. Chapter 1

Corrected extended response code for test 101. Chapter 2
Added info about new merchantCategoryCode element. Chapters 3 and4
Changed type and length parameters for the Chapters 3 and 4
authenticationTransactionId element and info about new
authenticationProtocolVersion element.
Added new Response Code: 170 - Submitted MCC not allowed. Appendix A

2.12 Modified results for tests 100 and 100 to reflect Chapter 2
extentedCardResponse element inclusion.

2.11 Corrected comments about supported card brands for CoF. Chapters 1 and 4
Added info about multiple daily deliveries of settlement transactions. Chapters 1 and 3
Added note about 20K character limit for Online request submitted by Chapter 3 and Appendix A
merchants using Open Access (i.e., Transact).
The duration element has a maxLength of 2 for Visa transactions. Chapter 4
Added info about the accountUpdateSource and Chapter 4
skipRealtimeAU elements.
Added response codes returned in the extendedCardResponse. Chapter 4
Added a new response codes: 507 related to account updates and Chapter 4 and Appendix A
740 related to the Visa duration limit noted above.
Corrected Visa card number in Table D-3. Appendix D

2.10 Removed all references to the Post-Live environment. Chapter 2

Corrected approvedAmount is test 31. Chapter 2
Removed Note about elements used for L2/L3 transactions. Chapter 4
Updated description of Response Code 550. Appendix A
Updated list of Dynamic Payout SSR reports. Appendix D

2.9 Updated Table 1-4 - Response Codes not recycled. Chapter 1

Updated tests DI3DS2 and DI3DS3 to return correct results. Chapter 2

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxiv
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

TABLE 1 Document Revision History

Doc.
Version Description Location(s)

2.8 Added certification test that returns the accountRangeId element. Chapter 2
Removed Notes from Dynamic Payout transactions stating that you Chapter 4
could not use both Online and Batch transactions.
Added Response Code 564. Appendix A
Added information about Dynamic Payout by direct merchants, Chapter 4 and Appendix D
including new transaction types and examples.

2.7 Rewrote tokenization section for OmniTokens. Chapter 1

Corrected Encryption Key note in Section 2.5.21. The key does not Chapter 2
expire in the Pre-/Post-Live environments.
Removed JCB entry from Credit Card Numbers table. The info in the Appendix C
Discover Card section still applies.

2.6 Removed Partial Approval bullet from Healthcare Card section. Chapter 1
Changed test card number in Table 2-10 (orderId Sale111111). Chapter 2

2.5 Corrected definition of tokenUrl element. Chapter 4

Changed Dynamic Payout overbalance message. Appendix D

2.4 Added Amazon Pay info and Cert tests. Chapters 1 and 2

2.3 Renamed eCheck to Direct Debit where applicable. All

Added Partial Approval bullet to IISA requirements. Chapter 1
Added note about Ruby SDK support ending at V12.3. Chapter 1
Added note about maximum filename length for Batch files. Chapter 2
Removed material for Sepa, IDEAL, Sofort, and Giropay. Chapters 1, 2, and 3
Added Not Supported notes to Sepa, IDEAL, Sofort, and Giropay Chapter 4
elements.
Added test card and Bin range for UnionPay 81 series card. Appendix B and C
Added CTX Information certification tests. Appendix D
Changed text to reflect new behavior for balance checking of Appendix D
Funding Instruction Batch files.

2.2 Removed Implementation section from Contact Info. Preface

Added Cert test for Refund Authorization. Chapter 2
Replace eCheck with Direct Debit, except element names. All
Added new elements for V12.7 of the schema. Chapters 3 and 4
Expanded the description of the authenticationValue element to Chapter 4
include its use in the Apple Pay Merchant Decrypt scenario.
Added Response Code 942, 943, and 944. Appendix A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxv
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

TABLE 1 Document Revision History

Doc.
Version Description Location(s)

2.1 Changed the list of allowed values for debitNetworkName. Chapter 4

Added space as an allowed character in the descriptor element. Chapter 4

2.0 Applied new Worldpay template and other related updates. All
Fixed broken link to Pre-live self-provisioning site. Chapter 2
Removed "not GA" Note about Online Funding Instructions. Appendix D
Corrected definition of advancedFraudResults, which stated all child Chapter 4
elements are required, but should be all optional.
NOTE: The schema changed from V12.5 to V12.6, but we did not None
introduce any new elements. The change involved one item moving
between schema files without impacting any features.

1.8 Began rebranding, changing Vantiv to Worldpay. All

Added Cert tests for Fast Access Funding. Appendix D
Modified Fraud Toolkit information, examples, and elements to reflect Chapters 1, 2, 3, and 4
the use of the webSessionId element instead of the
threatMetrixSessionId element.

1.7 Updated info about using stored credentials for Apple Pay and Chapter 1
Google Pay.
Added info about expanded capability of the Sandbox. Chapter 2
Corrected results for test Net_Id3. Chapter 2
Added note to totalHealthcareAmount. Chapter 4
Added new elements and cert tests for passing encrypted PAN and Chapters 2, 3 and 4
CVV in a Register Token Request.
Added new Response Code; 540 - Hard Decline - Decryption Failed. Appendix A

1.6 Added info about new standalone Fraud Check capabilities. Chapter 1
Removed tests 3DS17, 3DS18, and 3DS19 from the guide. Chapter 2
Added info about AmEx SafeKey (3DS) to element definitions. Chapter 4

1.5 Returned IIAS/Healthcare support info to the document. Chapters 1 and 2

Added Mastercard to notes about automatic Auth Reversal when Chapter 1
Capture is less than Auth amount.
Added Note about required fields for FastAccess Funding when Appendix D
pushing funds to a Mastercard.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxvi
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

TABLE 1 Document Revision History

Doc.
Version Description Location(s)

1.4 Added testing information for Visa Stored Credential scenarios. Chapter 2
Added new elements to support Preferred Debit Network. Chapters 3 and 4
Added info about new accountRangeId element. Chapters 3 and 4
Corrected allowed length of approvedAmount element. Chapter 4
Added webSessionId to advancedFraudChecks structure. Chapter 4
Added numTranslateToLowValueTokenRequests attribute to Chapter 4
batchRequest structure.
Changed deadline for Same Day Funding from 12:00 PM ET to Appendix D
11:00 AM ET.

1.3 Replace Android Pay info with Google Pay info Chapters 1 and 2
Updated the document for schema V12.2, including a new message Chapters 3 and 4
type for retrieving a low value token for a high value token, new
elements to support lodging transactions, and new elements for
standalone fraud checks. The lodging and token translate features
are not yet available for general use.

1.2 Added note about HTTP/1.0 and HTTP/1.1. Chapter 1

Added Response Codes 640, 641, and 642 for PINless Debit. Appendix A

1.1 Added info about Response Reason Code 825. Appendix A

Added info about allowing 60 second gap between a transaction and Chapters 1, 3, & 4
submitting a Void.
Added processingType enums for Card on File transactions. Chapter 4
Added the pinlessDebitResponse and networkName elements. Chapters 3 and 4

1.0 Initial release of cnpAPI Reference Guide for schema V12.0. This N/A
version eliminates "litle" from all element names, as well as removing
several unused/deprecated element.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxvii
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

Document Structure
This manual contains the following sections:

Chapter 1, "Introduction"
This chapter provides an introduction to transaction processing using cnpAPI.

Chapter 2, "Testing Your cnpAPI Transactions"

This chapter provides information concerning the testing and certification process, which you must
complete prior to submitting transactions to the Worldpay eComm production environment.

Chapter 3, "cnpAPI Transaction Examples"

This chapter provides information concerning the cnpAPI structure for transaction submission, as well as
examples.

Chapter 4, "cnpAPI Elements"

This chapter provides definitions and other information concerning each cnpAPI element.

Appendix A, "Payment Transaction Response Codes"

This appendix lists all of the possible response codes and messages.

Appendix B, "Credit Card Number Formats"

This appendix provides information about credit card number formats and Mod-10 validation.

Appendix C, "Test Card Numbers"

This appendix provides credit card number that can be used for testing.

Appendix D, "PayFac Dynamic Payout"

This appendix provides information about PayFac Dynamic Payout transactions.

Documentation Set
For additional information concerning the Worldpay application, see any of the following guides in the
documentation set:
• iQ Reporting and Analytics User Guide
• Worldpay eComm Chargeback API Reference Guide
• Worldpay eComm Chargeback Process Guide
• Worldpay eComm Partner Integration Overview Guide
• Worldpay eComm PayPal Integration Guide
• Worldpay eComm PayFac API Reference Guide
• Worldpay eComm PayFac Portal User Guide
• Worldpay eComm PayFac Integration Overview Guide

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxviii
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

• Worldpay eProtect Integration Guide

• Worldpay eComm cnpAPI Differences Guide
• Worldpay eComm Secure Scheduled Reports Reference Guide

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxix
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

Typographical Conventions
Table 2 describes the conventions used in this guide.

TABLE 2 Typographical Conventions

Convention Meaning

. Vertical ellipsis points in an example mean that information not

. directly related to the example has been omitted.
.

... Horizontal ellipsis points in statements or commands mean that

parts of the statement or command not directly related to the
example have been omitted.

<> Angle brackets are used in the following situations:

• user-supplied values (variables)
• XML elements
[] Brackets enclose optional clauses from which you can choose one
or more option.

bold text Bold text indicates emphasis.

Italicized text Italic type in text indicates the name of a referenced external
document.

blue text Blue text indicates either a hypertext link or an element name (in
xml examples).

monospaced text Used in code examples and elsewhere to designate field/element

names.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxx
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

Contact Information
This section provides contact information for organizations within Worldpay.
Chargebacks - For business-related issues and questions regarding financial transactions and
documentation associated with chargeback cases, contact the Chargebacks Department.

Chargebacks Department Contact Information

Telephone 1-844-843-6111

E-mail for Chargebacks: [email protected]

for Arbitrations: [email protected]

Hours Available Monday – Friday, 8:00 A.M.– 5:00 P.M. EST

Technical Support - For technical issues such as file transmission errors, email Technical Support. A
Technical Support Representative will contact you within 15 minutes to resolve the problem.

Technical Support Contact Information

Telephone For critical production issues only: 1-888-829-1907

E-mail [email protected]

Hours Available 24/7 (seven days a week, 24 hours a day)

Relationship Management/Customer Service - For non-technical issues, including questions

concerning iQ Reporting and Analytics, help with passwords, modifying merchant details, and changes to
user account permissions, contact the Relationship Management/Customer Service Department. If you
are a Payment Facilitator, refer to the second table.

Relationship Management/Customer Service Contact Information - Merchants

Telephone 1-844-843-6111 (Option 3)

E-mail [email protected]

Hours Available Monday – Friday, 8:00 A.M.– 6:00 P.M. EST

PayFac Account Management/Customer Service - For non-technical issues, including questions

concerning the user interface, help with passwords, modifying merchant details, and changes to user
account permissions, contact the PayFac Account Management/Customer Service Department.

TABLE 3 PayFac Account Management/Customer Service Contact Information

Telephone 1-844-843-6111 (Option 5)

E-mail [email protected]

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxxi
© 2020 FIS and/or its affiliates. All rights reserved.
 About This Guide

TABLE 3 PayFac Account Management/Customer Service Contact Information

Hours Available Monday – Friday, 8:00 A.M.– 5:00 P.M. EST

Technical Publications - For questions or comments about this document, please address your feedback to
the Technical Publications Department. All comments are welcome.

Technical Publications Contact Information

E-mail [email protected]

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

xxxii
© 2020 FIS and/or its affiliates. All rights reserved.
 1
Introduction

The cnpAPI data format supports two types of transaction submission methods: Online and Batch. With
the Online method, you submit each transaction independently and receive a response in real-time.
Typically, merchants use the Online method for Authorization transactions, as well as transactions
available only via Online (for example, Void). The Batch method enables you to submit multiple
transactions simultaneously in a single Session file. Worldpay recommends the Batch method for all
transaction submissions except Authorizations and the transaction available only via Online.
This chapter provides an overview of the cnpAPI data format, including some basic XML coding
requirements. Also discussed are the advantages of using batch processing, duplicate transaction
detection, report groups, Value Added Services, and supported transaction types.
The topics discussed in this chapter are:

• The cnpAPI Data Format • Fraud Toolkit

• Batch Transaction Processing • Tokenization Feature
• Payment Integration Platform (cnpAPI SDKs) • Direct Debit Processing
• Duplicate Transaction Detection • eCommerce Solution for Apple Pay™
• Coding for Report Groups • eCommerce Solution for Google Pay™
• Recovery • Amazon Pay
• Recurring Engine • Healthcare Card Feature
• Issuer Insights • Supported Transaction Types

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

1
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.1 The cnpAPI Data Format

There are several advantages to using the cnpAPI format as follows:

• Easier Implementation, Operations, and Debugging - Compared to fixed length or binary formats,
the XML format is considerably easier for operations staff to read and edit, using virtually any text
editor. This allows Worldpay’s Implementation, First Line Support, and Relationship Managers to
quickly communicate any issues and work with your own operations staff to make necessary
corrections without worrying about line lengths, padding or encoding.
• Fewer Downgrades - Since the cnpAPI format allows you to explicitly tie deposits to their associated
authorizations via the <cnpTxnId> element, your transactions qualify for the best interchange rates
at a higher frequency than with formats that do not support this transaction cross-referencing.
• Simpler Capture (Deposit) and Refund Transactions - Because the cnpAPI format associates
related transactions using the <cnpTxnId> element, our format does not require you to resubmit all
of the authorization information on a deposit nor all of the deposit information on a refund. When you
submit the unique transaction id, Worldpay automatically pulls the information from the original
transaction. Most other formats require you to resubmit the related data with each transaction.
• Superior Reporting - The cnpAPI format allows you to separate your transactions into different
categories by specifying a Report Group on each transaction. When accessing your data on the iQ
reporting and Analytics Interface, this feature allows you to filter your financial reports by Report
Groups, providing more granular detail based on a reporting hierarchy the Report Groups create.
Most other formats restrict reporting categories to a batch or specific merchant id.
• Improved Chargeback Management - Unlike most other formats where transactional relationships
can be a “best guess” proposition, the cnpAPI format explicitly ties related transactions, allowing you
and Worldpay to see authorization-to-deposit and deposit-to-refund relationships with precision. This
knowledge is indispensable when fighting chargebacks.
• New Features - New features developed for the Worldpay eCommerce platform are first exposed via
the cnpAPI. While the SDKs add new capabilities shortly after development, direct coding to the
cnpAPI gains access to these feature and capabilities earlier.

1.1.1 Communications Protocols

Worldpay supports the submission of Batch transactions to Worldpay eCommerce platform for processing
via sFTP and Online submissions via HTTPS POST, as shown in Table 1-1.

NOTE: Although the Worldpay eComm platform currently supports both TLS 1.1 and TLS 1.2,
Worldpay strongly recommends the use of TLS 1.2 to ensure the best encryption security.
Also, Worldpay eComm supports both HTTP/1.0 and HTTP/1.1, but recommends the use of
HTTP/1.1.

TABLE 1-1 Communication Protocol Support Matrix

Protocol Encryption Batch Online

HTTPS Post TLS 1.2 N/A Required

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

2
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-1 Communication Protocol Support Matrix

Protocol Encryption Batch Online

sFTP SSH Key Recommended N/A

The Worldpay eComm platform supports the following ciphers for the TLS 1.2 encryption protocol:

TABLE 1-2 Supported TLS Ciphers

Server Ciphe TLS 1.2 TLS 1.1

Priority r Id Cipher Name Support Support

1 c030 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Yes No

2 c02f TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Yes No

3 c028 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Yes No

4 c014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Yes Yes

5 c027 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Yes No

6 c013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Yes Yes

7 009d TLS_RSA_WITH_AES_256_GCM_SHA384 Yes No

8 009c TLS_RSA_WITH_AES_128_GCM_SHA256 Yes No

9 003d TLS_RSA_WITH_AES_256_CBC_SHA256 Yes No

10 003c TLS_RSA_WITH_AES_128_CBC_SHA256 Yes No

11 0035 TLS_RSA_WITH_AES_256_CBC_SHA Yes Yes

12 002f TLS_RSA_WITH_AES_128_CBC_SHA Yes No

1.1.2 General XML Coding Requirements

As part of the on-boarding process, you receive XML schema files from your Implementation Consultant.
Using those files and this document as a guide, you create the required XML documents for submission
of your transactions. You should validate all XML you create using the supplied schema. Also, working
with your Implementation Consultant, you are required to perform various tests of your XML (see
Chapter 2, "Testing Your cnpAPI Transactions") prior to submitting transactions to the production
environment.
In addition to the process outlined above, there are a few XML basics of which you should be aware.
• Encode all data using the UTF-8 format.
• Although it is not required, Worldpay recommends that when formatting your XML, you keep each
element on its own line. This will aid in debugging situations where an error message specifies an
issue in a particular line of XML code (for example, line 20).
• Be aware of special characters that require specific handling (see Table 1-3). For example, the less
than (<) and greater than (>) symbols define element tags in the XML code. Using the entity names
&lt; and &gt; instead of < and > prevents a browser from interpreting these characters as element
brackets.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

3
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Be sure to review data provided by customers for special character handling. For example, an
address of "4th & Main," must be rewritten as "4th &amp; Main" (including quotes) before being
submitted via XML. Failure to quote this type of input causes rejection of XML submissions due to
syntax errors.

TABLE 1-3 Coding for Special Characters

Character Description Entity Reference (case sensitive)

< less than &lt;

> greater than &gt;

“ quotation &quot;

‘ apostrophe &apos;

& ampersand &amp;

1.1.3 Other XML Resources

There are several Internet sites that provide both reference and educational information that may help you
when implementing your XML. A few of these sites are:
• http://www.w3schools.com/xml/xml_syntax.asp
• http://www.w3.org/
• http://www.utf-8.com/

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

4
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.2 Batch Transaction Processing

Batch processing involves a group of transactions submitted in a single file. In the case of a cnpAPI
Batch, the parent or root element is the <cnpRequest> element. A single <cnpRequest>, referred to as
a Session, can contain many batches and each batch can contain multiple transactions. We recommend
that you use Batch processing for all transaction types except Authorizations and Voids (Online only).
Some of the advantages of using Batch processing are:
• Better Performance - We optimize batch processing by processing multiple transactions in the batch
simultaneously. This allows you to process thousands of transactions quickly without writing
complicated logic or managing complicated processes.
• Easier Reconciliation - When processing a batch, all transactions within that batch post on the same
day. In the case of Online transactions, you could submit two transactions at the same time and one
could post today and the other tomorrow. This can cause confusion in your accounting process.
• Easier Error Recovery - A batch processes as a single unit, thus if you experience any system or
communication issue while processing a batch, you can easily determine if the file was processed.
With Online transactions, determining which individual transactions were not processed can be more
difficult.

1.2.1 Recommended Session File Size

As stated above, a Session file is a group of batches. A batch is a set of transactions for a single
merchant. Normally, you send in a single file which has one batch for each merchant. This works well
when the overall number of transactions is small. The number of transactions you should submit in any
individual Session or Batch depend on a number of factors, including whether or not you are an individual
merchant or a presenter submitting transactions for multiple merchants. In general, you should keep the
following recommendations and rules in mind when determining the number of transactions you submit in
an Session/Batch file:
• A Batch should not exceed 20,000 transactions. If the number of transaction for a single merchant
exceeds 20,000, you should create multiple batches for the same merchant, each batch containing
not more than 20,000 transactions.
• A Batch should not contain only one transaction, unless the merchant has only one transaction for the
day.
• A Session file must never contain more than 9,999 Batches.
• A Session file must never contain more than 1,000,000 transactions across all Batches.
• Always allow sufficient time between your submission time and your cut-off time for the processing of
the Session. Larger files take longer to process.

1.2.2 Multiple Daily Delivery

Starting on October 16, 2019, Worldpay will send multiple settlement files to the card networks each day.
We will send settlements files to the networks three hours after the timestamp of the submitted
transaction rounded up to the next hour. This enables us to align with the network settlement cutoff times.
This delivery schedule does impact Void transactions. If you wish to void a settlement transaction, you
must submit the void within three hours of submitting the settlement transaction. If it’s outside the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

5
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

three-hour window, you must send a Credit transaction to make the cardholder whole. Similarly, you will
have three hours to request us to discard a full Batch file with deposits.
There are two possible cases:

Case 1: End of Merchant Fiscal Day (or merchant Cutoff) Void Window
The three-hour window for Voids does not apply to the end-of-day delivery. This is how the system works
now and will continue to work. If a your cutoff time is 11 p.m., you cannot void a transaction after 11 p.m.
So, if your cut-off time is 11:00 PM and you submit a settlement transaction any time after 8:00 PM, you
will have less than three hours to Void the transaction.

Case 2: Multiple Daily Settlement Void Window

For any settlement transactions you submit more than three hours prior to your cut-off time you will
always have a minimum of three hours to void the transaction or discard a batch. This is independent of
when our deliveries schedule. When you submit a settlement transaction, we apply a time stamp of the
top of the next hour. For example, an Online transaction or a Batch that you submit at 1:05 PM receives a
2 p.m. time stamp. We determine the time stamp for Batch files based upon when you complete the
submission, not when you start. For both types of submissions, you have three hours from the time stamp
to submit a void or discard the Batch. So, you would have until 5:00 PM to void a transaction or discard a
Batch submitted at 1:05 PM (i.e., 2:00 PM time stamp + three-hour window = 5:00PM).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

6
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.3 Payment Integration Platform (cnpAPI SDKs)

In order to facilitate integration to the platform, Worldpay provides several language specific SDKs
(Software Development Kits). The developers page on our website (http://www.vantiv.com/developers)
provides links to SDK libraries for several popular languages, including:
• PHP
• Java
• .NET
• Python

NOTE: We discontinued support for the Ruby SDK after version 12.3. Please consult your
Relationship Manager for additional information.

Extensions for:
• Magento
• Opencart
In addition to the SDKs and extensions, Worldpay provides examples of each supported transaction type,
as well as demonstration applications. Once you install the library appropriate to your language, the
Worldpay Sandbox, which functions as an emulator of our production environment, is available to validate
your transaction format.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

7
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.4 Duplicate Transaction Detection

In order to help you avoid transaction errors, Worldpay performs duplicate transaction checking for both
Online and Batch transaction submissions. While we use a robust duplicate checking methodology, we
cannot guarantee our system will catch all duplicates and bear no responsibility for correcting the impact
of erroneously submitted transactions. This section discusses the different checking methodologies used
depending upon the type of submission.

NOTE: For tokenized transactions, the token is used in place of the card numbers by the Duplicate
Transaction Detection process.
For PayPal transactions a combination of the PayPal Id + the (consumer’s) email is used by the
Duplicate Transaction Detection process.
For transactions submitted using other formats (e.g., PTI, Nabanco, etc.), the logic used to detect
duplicates for these supported, but foreign APIs, is less robust and may miss duplicates in certain
scenarios. Worldpay recommends, for better dupe checking, convert to the cnpAPI format, as soon
as possible.

1.4.1 Batch Duplicate Checking

When processing a Batch, the system acts to detect duplicate transactions for the following transaction
types: Authorization, Auth Reversal, Capture, Force Capture, Capture Given Auth, Credit, Sales, eCheck
Credit, and eCheck Sales.

NOTE: For information about duplicate checking of Dynamic Payout Funding Instructions see Batch
Dupe Checking for Dynamic Payout Funding Instructions on page 9.

For each of these transaction types, the application compares the transaction type, transaction amount,
the <orderId> element from the request, credit card number, and credit card expiration date against
transactions in other Batch processed within the previous five days. If the characteristics of the new
transaction match a previously processed transaction, the system marks it as a duplicate.
The system only performs duplicate detection against valid transactions from the previous five days. For
example, if an Authorization request matches a declined Authorization from the previous day, the system
would not count it as a duplicate, because the declined Authorization was not a valid Authorization.
Also, a Batch must be processed completely to be included in the previous five days of data. For
example, if multiple submitted Batches are processing simultaneously, the system will not compare the
transactions in one batch with the transactions in the other, because neither has completed processing.
For this same reason the system cannot detect duplicate transactions within the same Batch.
If the system detects ten consecutive duplicate transactions or if the number of duplicate transactions is
greater than or equal to 25% of the total transactions in the batch, the system flags the Batch as a
duplicate. When either threshold is met, Worldpay does not process the Batch. If neither threshold is met,
Worldpay continues processing the Batch, including any duplicate transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

8
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.4.1.1 Batch Dupe Checking for Dynamic Payout Funding Instructions

Duplicate checking for funding instructions takes place at the Batch level. The system compares a
submitted Batch of instructions to other Batches submitted and accepted on the same day. If a submitted
Batch has the same totals and counts as a Batch accepted on the same day, the system rejects the new
Batch as a duplicate. If you resubmit a previously rejected Batch, it will not fail dupe checking, because
the initial submission was not accepted and is not included in dupe checking comparisons.

NOTE: If you believe we rejected a funding instruction Batch in error, please contact your Partner
Account Manager. If necessary, we can disable the dupe check feature for a particular Batch.

1.4.2 Online Duplicate Checking

When processing an Online transaction, the system acts to detect duplicate transactions for the following
transaction types: Auth Reversal, Capture, Force Capture, Capture Given Auth, Credit, Sales, eCheck
Credit, eCheck Sales, eCheck Void, and Void, as well as Gift Card transactions.
For most transactions, the system compares the transaction type, the id attribute from the request, and
the credit card number against other Online transactions processed within the previous two days. For
transactions that reference other transactions (for example, a deposit referencing an authorization or a
refund referencing a deposit), the system compares the transaction type, id attribute, and the card
number from the referenced transaction (i.e. the transaction identified by the <cnpTxnId> element)
against other Online transactions processed within the previous two days.
The system only performs duplicate detection against valid transactions. For example, if a Capture
request matches a declined Capture from the previous day, the system would not count it as a duplicate,
because the declined Capture was not a valid transaction.

NOTE: While it is uncommon, under certain circumstances network latency may cause a duplicate
Sale transaction to go undetected. This can occur if you submit a second, duplicate Sale transaction
while the response from the network for the Authorization portion of the first transaction is sufficiently
delayed such that the first Sale has not been recorded as a valid transaction in the system.
If you elect to submit Online Sale transactions, Worldpay recommends a timeout setting of not less
than 60 seconds to reduce the chances of undetected duplicate Sale transactions.

If the system determines a transaction to be a duplicate, The duplicate transactions appears in the
Declined Transaction report with a Response Reason Code of 251 - Duplicate Transaction. You can
access this report in Worldpay eComm iQ or via the Worldpay eComm Secure Scheduled Reports. The
iQ version provides information in near real-time, while the SSR version runs daily, providing information
for the transaction submitted the previous day.

NOTE: If you do not receive a response for a submitted transaction, Worldpay recommends you
use the queryTransaction to determine the status of the original transaction (see Status Query
Transactions (Online Only) on page 286).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

9
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.5 Coding for Report Groups

You use Report Groups (reportGroup attribute) to separate your transactions into different categories,
so you can view the financial reports by your specific report group names. If you are unsure what
groupings to use, your Relationship Manager can help you determine the best practice for your business.

CAUTION: Creation of an excessive number of Report Groups (in excess of 250) will impact the
amount of time require to compile various reports in the iQ. Report Groups are intended to allow you
to segregate transactions by logically grouping them into the different segments of your business.
Report Groups are not intended to track sales or marketing programs that exist for limited times. For
this type of tracking, Worldpay provides other transaction tagging methods detailed in
Additional/Alternate Methods of Tagging Transactions on page 11.

Example: Report Groups

The merchant, Demo, wants to separate their domestic and international sales information. To do this the
company submits all domestic transactions using reportGroup = "Domestic Business", and all
international transactions using reportGroup = "International Business". When they access the
Authorization Report in the iQ using the By Reporting Group tab, the transactions would be separated as
shown in Figure 1-1.

NOTE: The reportGroup attribute is case and space sensitive. A reportGroup = “Picture
Frame” is a different report group than a reportGroup = “pictureframe”.

FIGURE 1-1 Report Group Example - 2 Groups

The plus sign next to the Domestic Business report group signifies that there are child groups present.
When fully expanded (see Figure 1-2), the iQ shows a report group hierarchy with information for the
Domestic Business group further separated into Service A and Service B groups and Service A
containing two additional child groups. If you find it necessary to establish this type of nested hierarchy,
your Implementation Consultant will assist you.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

10
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

FIGURE 1-2 Report Group Example - Expanded to Show Child Groups

1.5.1 Additional/Alternate Methods of Tagging Transactions

If you are using schema version 7.x or above you can use the merchantData element and its children to
tag transactions (Authorization, Sale, Credit, Force Capture, Capture Given Auth, eCheck Sale, and
eCheck Credit) with additional information. The three children of merchantData: campaign,
affiliate, and merchantGroupingId, allow you to designate transactions as members of different
groups enabling a deeper analysis of sales patterns.
For example, if the merchant from the previous example were trying a new sales initiative for Product 2
during the month of September. They plan to run ads in Boston and New York to test the new offering. To
allow a deeper analysis of sales resulting from the new campaign, they can add the campaign element
with a value of "September Ads" to the transactions originating in both test market. They can also include
the merchantgroupingId with values that reflect the city where the order originates. By exporting
either the Session report or the NSS by Transaction report from the iQ, the company can sort their sales
data based upon these fields and gain a better understanding of the effectiveness of the sales campaign.

NOTE: The transaction tagging elements described above appear in the exported Session and
NSS by Transaction reports. They are also visible within the iQ in the new Transaction Detail
reports.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

11
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.6 Recovery

Recovery is a bundle of services that include both Account Updater and Recycling Engine. By combining
these two managed services into a single bundle, Worldpay simultaneously increases your approval
rates, optimizes customer lifetime value, and improves your cash flow, while reducing the cost of
implementing the individual features separately in terms of IT resources. For additional information about
the capabilities included in this bundle, please refer to Recycling Engine on page 12, and (AAU) Account
Updater Service on page 14.

1.6.1 Authorization/Sale Recycling

Authorization recycling is the process of retrying declined authorization attempts. Every merchant,
especially those with a business model that uses recurring or installment payments, should devise a
strategy for dealing with declined authorizations. As part of optimizing their operations, merchants must
devise plans for both the timing and number of recycling attempts before contacting the cardholder or
risking interruption of service. If a merchant does not recycle enough, they risk losing customers and
revenue; whereas, if the merchant recycles too often, they risk increasing their total cost of payments.
Implementing an optimal recycling strategy aids customer retention and therefore yields higher revenues,
while lowering the costs of payment acceptance and improving cash flow.

1.6.1.1 Recycling Engine

The Recycling Engine is a managed service that automatically retries declined authorization attempts on
your behalf. It requires little or no IT investment on your part. Also, implementing the Worldpay service
removes the need to plan your own recycling strategy.
Recycling Engine has the following benefits:
• Increases approval rates
• Shortens time to approval, improving cash flow
• Reduces the number of authorization retries
• Lowers the risk of account/service cancellation
In order to determine the most effective recycle timing, Worldpay performs statistical analysis of past
recycling attempts across our entire merchant portfolio. This analysis examines many factors, including
method of payment, response codes, and transaction amount among others, to determine the optimum
intervals between attempts to obtain a successful authorization. When you receive a declined
Authorization, the system automatically queues the transaction for a retry at a designated time. Recycling
of the Auth continues until it is either successful or the algorithm determines that it is no longer
advantageous to retry.

NOTE: For Visa transactions, the Recycling Engine will retry declined Authorizations a maximum of
4 times within 16 days, per Visa regulations. For Mastercard, American Express, and Discover
transactions, we retry declined Authorizations a maximum of 7 times within 27 days.

Worldpay provides the results of the recycling efforts to you in a Batch posted daily to your Worldpay
sFTP account. This file contains transactions that either approved or exhausted the recycling pattern on
the previous day. If you submit an Authorization for a transaction in the recycling queue, Worldpay returns

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

12
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

the response from the last automatic recycling attempt. To halt recycling of a particular transaction,
submit either an Authorization reversal transaction, if the original transaction was an Auth, or a Void
transaction, if the original transaction was a Sale.

Declined Transactions Not Recycled

Table 1-4 below provides information about Response Codes not recycled by the Recycling Engine,
except under the conditions noted. The <recycleEngineActive> element in the response files indicates if
the transaction is being handled by the Recycling Engine.

TABLE 1-4 Response Codes Not Recycled (except as noted)

Response
Code Message Recycling Behavior

213 Pickup Card - Lost Card Only recycled if card repair information is
available.

214 Pickup Card - Stolen Card Only recycled if card repair information is
available.

229 Illegal Transaction Does not recycle.

301 Invalid account number Not recycled for Mastercard, unless updated
account information is available.

303 Pick up Card Only recycled if card repair information is

available.

304 Lost/Stolen Card Only recycled if card repair information is

available.

305 Expired Card Only recycled if card repair information is

available.

308 Restricted Card - Chargeback Only recycled if card repair information is

available.

309 Restricted Card - Prepaid Card Filtering Only recycled if card repair information is
Service available.

312 Restricted Card - International Card Filtering Only recycled if card repair information is
Service available.

315 Restricted Card - Auth Fraud Velocity Only recycled if card repair information is
Filtering Service available.

318 Restricted Card - Auth Fraud Advice Only recycled if card repair information is
Filtering Service available.

319 Restricted Card - Fraud AVS Filtering Only recycled if card repair information is
Service available.

323 No such Issuer Only recycled if card repair information is

available.

328 Cardholder requested that recurring or Does not recycle

installment payment be stopped

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

13
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-4 Response Codes Not Recycled (except as noted)

Response
Code Message Recycling Behavior

358 Restricted by due to security code mismatch Only recycled if card repair information is
available.

550 Restricted Device or IP - ThreatMetrix Fraud Only recycled if card repair information is
Score Below Threshold available.

Transaction Signature
The Recycling Engine analyzes each Authorization or Sale request message to determine if it is a new
request. The result of the analysis determines if the transaction should be added to the recycling pool
upon decline or if the system should intercept the transaction to prevent a duplicate transaction entering
the recycling pool. To perform the analysis, the system checks the transaction signature. Depending upon
your configuration, the transaction signature can be:
• Value of the <recycleId> element
• Value of the <orderId> element
• Values of the <orderId>, <number>, and <amount> elements

NOTE: If you submit a transaction with the identical signature, but containing new information (for
example, a new card number), the system updates the transaction in the recycling pool with the new
info and continues to recycle.

Additional Configuration Options

The Recycling Engine allows you the additional flexibility of excluding certain transactions from automatic
recycling. You can exclude transactions manually by including the <recycleBy> element set to None.
There are also global controls that allow you to exclude transactions based upon either submission by a
particular presenter, or based upon the transaction type (authorization or sale). Please consult your
Relationship Manager about the global options, since they must be configured in your Worldpay Merchant
Profile.

1.6.2 Account Updater Service

Credit and debit card numbers change for a variety of reasons including card expirations, card product
type upgrades, portfolio conversions, and compromised account numbers among others. For merchants
who offer services that are billed on a recurring or installment basis (for example, web hosting, gym
memberships, specialized social networking, career services, monthly donation plans, etc.) out-of-date
payment information can result in lost revenue, involuntary churn and decreased customer satisfaction.
Prior to the development of the Account Updater service, the standard method for merchants to obtain
updated account information was to submit a Batch containing existing card information, requesting that
Worldpay check for updates. Typically, merchants request updates for customer accounts scheduled to
be billed in the next billing cycle. This legacy method is a relatively slow process, requiring several days
for Worldpay to accumulate responses from the card networks/issuers and then to make the response file
available to the merchant. Merchants must then update their billing systems with the new information,
requiring IT processing cost. Failure to update their files can result in multiple requests (and charges) for

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

14
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

the update information, as well as delays in or lost revenue, higher Authorization expenses, and possibly
chargebacks when old account information is used.
The Account Updater service shifts the workload of obtaining and maintaining updated account
information to Worldpay. Utilizing configurable scheduling algorithms, we initiate account update requests
on your behalf and then store the updated card information for use in future transactions. You simply
submit billing transactions normally and, if necessary, Worldpay updates the transaction with the stored
card information before submitting it to the networks for authorization. This fully managed service requires
no code update on your systems.

FIGURE 1-3 Account Updater Overview

Merchant Card Networks

Scheduled Response
AU Requests with
updates
Process from
and Network
Store
Matches

Submit Worldpay Submits

Transaction Auth w/Repaired Auth
Card Info (if info
on file)

Worldpay Adds Auth Decline if updated

Account Info to info not yet on file

Next Scheduled
AU Request

Re-Submit Worldpay Repairs

Transaction Auth
Card Info and
(+ 3 days) Submits Auth
Auth Approval
Auth Approval

1.6.2.1 Match Back

If you decide you wish to have the updated card information returned to you, Worldpay offers the Match
Back option. In this case, you can opt to receive updated information either in a Batch deposited to the
merchant sFTP account, or in the XML transaction response messages. Once you update your systems,
you can resubmit the failed transaction with the new card information. If, after receiving an update, you

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

15
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

submit a transaction with the old information, systems detect that you are using the old data and update
the transaction for you prior to submitting it to the networks for authorization.
Please consult your Relationship Manager for additional information and configuration options.

FIGURE 1-4 Match Back Overview

Merchant Card Networks

Scheduled Response
AU Requests with
updates
Process from
and Store Network
Matches

Submit Worldpay Submits

Transaction Auth w/Repaired Auth
Card Info (if info
on file)

Worldpay Adds Auth Decline if updated

Account Info to info not yet on file

Next Scheduled
AU Request

Re-Submit Worldpay Repairs

Transaction Auth
Card Info and
(+ 3 days) Submits Auth
Auth Approval w/New
Auth Approval w/New
Card Info
Card Info

(Next
Payment)
Submit Submit for Auth Auth
Transaction
w/New Info

1.6.2.2 Merchant Requirements

In order to use the Account Updater service, you must first apply for membership to the following:
• Mastercard Automatic Billing Updater
• Visa Account Updater
• Discover Account Updater (not required by Discover for Worldpay acquired merchants)

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

16
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Your Account Updater Welcome Kit includes the required application forms. If you have any questions
about these forms, contact your Relationship Manager, who can walk you through the application
process. Approval from Visa and Mastercard typically takes between 10-15 business days. Normally,
merchants are approved without issue; however, you can be declined for a variety of reasons. For
example, merchants on a risk mitigation program typically are not accepted.

NOTE: Visa does not allow merchants with SIC numbers 5962, 5966, 5967, or 7995 to participate
in their Account Updater service. Mastercard has no restrictions against any specific MCC numbers.

1.6.2.3 Account Updater Features

The Account Updater service can include the following features depending upon the implementation
option you select:
• Worldpay initiates requests for updated account information to card networks based upon your billing
cycle.
• Worldpay initiates requests for updated account information following certain failed Authorization
attempts.
• All updated card information stored (per merchant) in our secure database.
• Automatic repair/replacement of outdated information with updated information in new
Authorization/Sale transaction submissions.
• Return of the updated account information in the cnpAPI response message when auto-repair occurs.
• Maintenance of card information history, so that the system can repair a card even if multiple updates
have occurred during the card's billing lifecycle.
• All linked (to an Authorization) transactions will use the updated account information from the repaired
parent transaction, including Captures, Refunds, and Reversals. If a re-Auth is needed on an
attempted capture due to an expired authorization, the system uses the updated account information.
• Integration with Vault for merchants utilizing Worldpay’s tokenization solution.
• Return of Extended Response Codes in the cnpAPI response messages.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

17
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.7 Recurring Engine

The Recurring Engine is a managed service that relieves the burden of developing an in-house billing
solution for merchant engaged in installment or recurring transactions. This powerful, but flexible service
allows you to create virtually any payment Plan required by your business model, whether it is part of a
predetermined campaign or a marketing test, and then apply the Plan to customers as part of the
standard Authorization or Sale transaction.
The Recurring Engine provides the following benefits:
• Reduced Infrastructure Costs - since you do not need to program your own solution, you save the
up-front development cost, as well as ongoing maintenance expenses.
• Reduced Labor - once you create a Subscription in the Recurring Engine via a standard
Authorization or Sale transaction, no further action is required for the life of the Subscription.
• Integration with other Worldpay Value Added Services - if you include the Recovery Services
(Account Updater and Recycling Engine) as part of your implementation, you eliminate any concerns
(and reduce expenses) associated with issues such as account number changes and recycling of
declined payments.
• Flexible Plans - You can define the billing interval (weekly, monthly, quarterly, etc.), number of
payments (including open ended schedules), amount of payments, as well as trial periods within a
Plan. To add flexibility you can override several of these settings and set a specific start date at the
individual Subscription level.
• Flexible Creation of Discounts - if you wish to offer a discount to selected customers, simply include
the information at the time of the Subscription creation, or add it anytime afterward by updating the
Subscription.
• Flexible Creation of Add Ons - similar to a discount, you can apply changes for additional services
at the time of the Subscription, or anytime afterward.
• Integrated Reporting - in addition to the normal revenue reconciliation information available in the iQ
Reporting and Analytics platform, there are a number of recurring specific reports that allow you to
better analyze your revenue stream associated with recurring payment plans and strategies.

1.7.1 Payment Plans

The first step in setting up recurring billing on the Worldpay eCommerce platform is to establish one or
more payment Plans. To establish a payment Plan you use a Create Plan transaction type, which allows
you to define the payment interval, the number of payments, and the amount. For example, you could
easily define any number of Plans to fulfill your business needs.
For example, suppose you are a SaaS company that sells your product under 1, 2, or 3 year deals, with
either monthly or quarterly payment schedules and reduced rates for longer deals. You could easily
set-up six Plans as shown in the table below.

TABLE 1-5 Example Pans

Payment Amount per # of

Plan Code Interval Payment Payments Total Subscription
1_Year_Monthly Monthly $50.00 12 $600.00

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

18
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-5 Example Pans

Payment Amount per # of

Plan Code Interval Payment Payments Total Subscription
1_Year_Quarterly Quarterly $150.00 4 $600.00
2_Year_Monthly Monthly $46.66 24 $1119.84
2_Year_Quarterly Quarterly $140.00 8 $1120.00
3_Year_Monthly Monthly $41.66 36 $1499.76
3_Year_Quarterly Quarterly $125.00 12 $1500.00

As part of the Plan, you can also specify trial period. You want to have longer trials for longer Plans, so for
either 1-year Plan, there is a 1 week trial, for either 2-year Plan there is a 2 week trial, and for the 3-year
Plans, a 1 month trial. Below is a cnpAPI example transaction to create the 3_Year_Monthly Plan.

Example: 3-Year Monthly Plan

<createPlan>
<planCode>3_Year_Monthly</planCode>
<name>3Year_Monthly</name>
<description>3 Year, monthly Payments, 1 month trial</description>
<intervalType>MONTHLY</intervalType>
<amount>4166</amount>
<numberOfPayments>36</numberOfPayments>
<trialNumberOfIntervals>1</trialNumberOfIntervals>
<trialIntervalType>MONTH</trialIntervalType>
<active>true</active>
</createPlan>

1.7.2 Subscriptions
Subscriptions marry a customer order to a particular payment Plan and initiate the Recurring Engine to
manage your future billing. You create a Subscription using either an Authorization or a Sale transaction.
In the Auth/Sale you simply include a <recurringRequest> element to initialize the Subscription using
a named Plan and set the start date for the first recurring bill. If you do not include a start date, the
Recurring Engine uses the current date for the first payment.
If the recurring bill had an associated set-up or one-time fee use a Sale transaction. The amount of the
Sale transaction would represent that fee, whereas the amount of future recurring payments are defined
in the Plan. If you use an Authorization to create the Subscription, the transaction would normally be a $0
Auth (or small amount followed by a reversal) and would include the billing information for Address
Verification.
As part of the Subscription creation, you can also override both the number of payments and the amount,
as well as include Add Ons and Discounts (discussed in the next section). The overrides give you a
granular control to modify a standard payments Plan for a particular consumer without creating additional

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

19
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Plans. For example, if you offered a 1-year Plan with monthly payments as shown in the previous section,
you could allow a consumer to complete their payments in 10 months instead of a year. In this case you
would override the number of payments defined in the Plan (12) with 10 payments, while increasing the
amount of each payment from $50 to $60.

Example: Subscription with Overrides

<authorization id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>0</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
.
.
.
</billToAddress>
<card>
.
.
.
</card>
<recurringRequest>
<subscription>
<planCode>1_Year_Monthly</planCode>
<numberOfPayments>10</numberOfPayments>
<startDate>2016-09-21</startDate>
<amount>6000</amount>
</subscription>
</recurringRequest>
</authorization>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

20
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.7.2.1 Add Ons and Discounts

Occasionally, you might wish to modify a Subscription with either a Discount or an Add On without
creating a new Plan that has limited use. A Discount reduces the recurring amount for one or more
payments, while an Add On increases the payments in return for an added service or item. You can apply
either of these payment modifications at the time you initialize the Subscription or anytime afterward by
updating the Subscription. In both cases you define the start date, end date, and amount of the
Discount/Add On.
For example, suppose as part of your standard offering, your customers received 2GB of cloud-based
storage. You also offer additional storage in 2GB blocks for $10 each. One of your customers wants an
additional 4GB of storage for the 8 months remaining on his contract and you are discounting the first
month at 50%, or $10. The example below show the updateSubscription transaction with the Add On
and Discount.

Example: Update Subscription with Discount and Add On

<updateSubscription>
<subscriptionId>1234</subscriptionId>
<createDiscount>
<discountCode>4GBExtraDeal</discountCode>
<name>Half-Off 1st Payment 4GB Extra</name>
<amount>1000<amount>
<startDate>2016-09-15</startDate>
<endDate>2016-10-14</endDate>
</createDiscount>
<createAddOn>
<addOnCode>4GB_Extra</addOnCode>
<name>Four_GB_Extra</name>
<amount>2000<amount>
<startDate>2016-09-15</startDate>
<endDate>2016-04-15</endDate>
</createAddOn>
</updateSubscription>

1.7.3 Recurring Reports

In addition to recurring transactions appearing in the normal Worldpay reports (i.e., Payment Detail,
Reconciliation report, etc.), there is an additional report associated specifically with the Recurring Engine.
Available via sFTP, this report is in Batch format and contains cnpAPI saleResponse messages for all
recurring transactions run that day, including all approvals and declines (see the example, Batch Sales
Response with Recurring Info on page 308).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

21
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.7.4 Transaction Types and Uses

The table below provides information about the various Recurring Engine transaction types and their
uses.

TABLE 1-6 Recurring Engine Transaction Types

Use Case/Intent Parent Element Description/Uses

Create Plan createPlan Used to create new Plans.
updatePlan Used to toggle a Plan between an active
and inactive state. You can not associate
an inactive Plan with a Subscription.
Update Plan
Toggling a Plan to an inactive state does
not affect existing Subscriptions
associated with the Plan.
<authorization> or <sale> Used to initiate a Subscription with an
<recurringRequest> associated Plan. The Subscription can
include amount and numberOfPayment
Create Subscription <subscription> overrides to the Plan. Also, the
Subscription can include createAddOn
and createDiscount children.
updateSubscription Used to modify Subscription information
including: changing the Plan, changing
the billing name/address, and changing
Update Subscription the method of payment. You can also
use this transaction type to
create/delete/update Add Ons and
Discounts.
Cancel Subscription cancelSubscription Used to cancel an existing Subscription.
<authorization> or <sale> Used to create an Add On charge
<recurringRequest> associated with the Subscription.

<subscription>
Create Add On <createAddOn>
Or
<updateSubscription>
<createAddOn>
<updateSubscription> Used to modify one or more of the
Update Add On parameters associated with the Add On.
<updateAddOn>
<updateSubscription> Used to delete an Add On charge from
Delete Add On the associated Subscription.
<deleteAddOn>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

22
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-6 Recurring Engine Transaction Types

Use Case/Intent Parent Element Description/Uses

<authorization> or <sale> Used to create a Discount charge
<recurringRequest> associated with the Subscription.

<subscription>
<createDiscount>
Create Discount
Or
<updateSubscription>
<createDiscount>

<updateSubscription> Used to modify one or more of the

Update Discount <updateDiscount> parameters associated with the
Discount.
<updateSubscription> Used to delete a Discount from the
Delete Discount associated Subscription.
<deleteDiscount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

23
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.8 Issuer Insights

Issuer Insights provides you additional card/transaction, performance descriptive data, allowing you to
understand the differences among Issuers and card products, and identify trends that may impact future
transactions. Currently, Worldpay bundles four feature sets into Issuer Insights: the Issuer Insights Secure
Scheduled Report, Real Time Indicators (i.e., Prepaid Indicator, Affluence Indicator, Issuer Country
Indicator, Card Type Indicator), Network Response Data, and the Insights Analytics Dashboard.

1.8.1 Issuer Insights Secure Scheduled Report

Every merchant wants to maximize their approval rate and with it their customer conversion rate and
sales. Unfortunately, issuing banks do not all use the same criteria and/or algorithms when approving or
declining transactions. Getting an approval on an authorization is not a one size fits all proposition.
The weekly Issuer Insights report provides a range of data points that breakdown authorization approvals
and declines by card type, BIN (i.e. Issuing Bank), and account ranges (indicating card product types). It
also provides data about the four of the most often seen reasons for declines (i.e., Non-sufficient Funds,
Do Not Honor, Invalid Account, and Lost/Stolen Card), as well as benchmark data for your MCC(s) across
the Worldpay eComm portfolio, and Issuer participation in AU, as well as account update counts per
account range across our portfolio. Using this data, you can create a wide range of useful analytics, such
as approval/decline trending by BIN, account updates trending by account range, new card
issuance/portfolio changes, or customer lifetime value by card type to name a few.
For additional information about this report please refer to the Worldpay eComm Scheduled Secure
Reports Reference Guide.

1.8.2 Real Time Indicators

The Real Time Indicators provide six data points in the Authorization/Sale transaction response message.
This information includes the Prepaid Indicator, Affluence Indicator, Issuer Country Indicator, Card Type
Indicator, Funding Source Indicator, and Virtual Account Number Indicator. Each of these pieces of
information allows you to make a real time decision about how to proceed with the transaction. The
sections that follow explain each indicator along with possible uses in your decision making process.

1.8.2.1 Prepaid Indicator

Studies show that branded prepaid cards are growing in popularity with consumers. These cards are
available in the form of non-reloadable Gift cards, Consumer Rebate/Incentive cards, and Teen cards
among others. The Prepaid Indicator feature acts to determine if the submitted card is a prepaid card. If
so, the system returns the type element with a value of Prepaid and the availableBalance element
stating the outstanding balance remaining on the card (if available).
Knowing that the card is prepaid at the time of sale, as well as if it is reloadable and the available balance,
is especially useful for merchants engaged in recurring payment, installment payment, or deferred billing
scenarios. Merchants in these situations can use the information made available by this feature to make
intelligent decisions concerning the profitable management of prepaid card usage by avoiding several
factors that may contribute to lost revenue, while taking advantage of other opportunities that may add to
revenue and enhance the customer experience.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

24
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

For example, one possible situation merchant can avoid is fraudulent deferred/installment payment
purchases made with a prepaid card that does not have enough available balance to cover the
subsequent payments. With the available balance known, merchants can determine if the card can meet
the required payment structure. If the card’s balance does not meet the required threshold, the merchant
can request another payment method, which may result in eliminating fraudsters, while retaining
legitimate customers. If the card is non-reloadable, it is advisable to not accept the card at all for recurring
payments regardless of the available balance.
Another more common situation occurs when the consumer is unaware of the card balance. If the
transaction is rejected due to inadequate balance, perhaps repeatedly, it could result in an unsatisfied
customer and an abandoned purchase. Alternately, the card could have slightly more that the required
balance, which the consumer would spend, if they had the knowledge. If the available balance is
insufficient for the purchase, the merchant can obtain a second or alternate payment method. If the
balance is higher than required for the purchase, the merchant may be able to encourage additional
purchases.
In addition to indicating if the submitted card is a prepaid card and the available balance, this feature
includes information about whether the card is reloadable and the specific type of prepaid card (e.g.,
TEEN, GIFT, PAYROLL, etc.). You can use this information to further refine your sales and marketing
strategies.

1.8.2.2 Affluence Indicator

Visa, Mastercard, and Discover provide enhanced credit card products for consumers with high
disposable incomes and high card spending. These cards encourage usage by offering the cardholders
additional benefits usually including reward incentives, no pre-set spending limit, higher authorization
approval rates, faster access to a customer service representatives, and dedicated chargeback resolution
support.
Worldpay analysis of payments data indicates that consumers using these cards types typically spend
more per order than consumers using traditional credit and debit cards. The Affluence Indicator feature
provides the ability for merchants to segment their consumers based on the affluence level as determined
by the issuer. Within the cnpAPI Authorization response, consumers using these enhanced card products
are classified either as Mass Affluent or Affluent. Based upon the specific card type, high income
consumers are classified as Mass Affluent, while high income-high spending consumers are classified as
Affluent.
Having this information at the time of authorization, allows merchants the opportunity to adjust their sales
approach to the needs and spending patterns of the consumer, potentially generating additional sales.
Having this information on file for later analysis also may provide the opportunity for targeted marketing
campaigns and future sales.

1.8.2.3 Issuer Country Indicator

Knowing the country of the Issuing bank helps you in two respects. From a sales and marketing
standpoint, this knowledge allows you to better analyze the purchasing patterns of your customers based
upon their country of origin. Knowing these customer demographics can allow you to tailor marketing
campaigns to take advantage of this geographic information. Likewise, you can use this information to
analyze the successfulness of tailored campaigns.
The second advantage to having this information readily available is that you can use it to help determine
possible patterns of fraud. With this knowledge in hand, you can use the International Card Filtering
feature to limit your exposure to international fraud originating in particular geographic locations.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

25
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.8.2.4 Cardholder Type Indicator

The Card Holder Type indicator is an additional data point Worldpay provides as part of Issuer Insights.
This indicator returns an element specifying whether the submitted card is a commercial or consumer
card, providing you with additional data useful when analyzing sales patterns and/or planning marketing
campaigns, such as offering different products/services to a corporate customer as opposed to a regular
consumer.

1.8.3 Extended Network Data

In an effort to provide more data for use in analyzing your transactions and customers, Worldpay added a
number of data elements originating directly from the ISO 8583 network response messages. If you use
V11.0 or above of the Worldpay cnpAPI, you can receive up to 17 data elements as part of the Enhanced
Auth Response (<enhancedAuthResponse> element). These elements provide more granular data,
allowing you to gain a more nuanced understanding of the approval/decline behavior of particular Issuers.
Table 1-7 provides information about the fields returned.

NOTE: To receive the Extended Network Data elements you must code to Version V11.0 or above.

TABLE 1-7 Possible Extended Network Data ISO 8583 Fields

Data
Element Field Name Type Notes

4 Transaction Amount n 12
15 Settlement Date n4 MMDD format
38 Authorization Identification an 6
Response
39 Response Code an 2
44 Additional Response Data an..25
48 Private Use Additional Data an...999
50 Settlement Currency Code n3 Defines the currency of the settlement
51 Cardholder Billing Currency n3
Code
54 Additional Amounts an...120
63 Reserved Private an...999
104 Transaction Description an...100
116 Reserved for National Use an...999
123 Reserved for Private Use an...999

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

26
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Example: Extended Network Data

<enhancedAuthResponse>
.
.
.
<networkResponse>
<endpoint>VISA</endpoint>
<networkField fieldNumber="4" fieldName="Transaction Amount">
<fieldValue>000000000962</fieldValue>
</networkField>
<networkField fieldNumber="44" fieldName="Additional Response Data">
<networkSubField fieldNumber="0">
<fieldValue></fieldValue>
</networkSubField>
<networkSubField fieldNumber="1">
<fieldValue>5</fieldValue>
</networkSubField>
</networkField>
</networkResponse>
</enhancedAuthResponse>

1.8.4 Insights Analytics Dashboard

The Insights Dashboard provides insight into the quality of customers your organization acquires, based
on the number and percentage of authorizations by card type or other indicator, and contrasts that with
the number of customers whose authorizations are successfully converted to deposits. There are four
categories of indicators: Affluence, Prepaid, Corporate Customers, and Country of Issuing Bank.
Using these values and the related charts, your organization can decide whether the customer mix you
attract yields maximum revenue potential, or if a change in marketing is required. By using the adjustable
date range and reporting groups, you can compare the quality of customers between different business
units and affiliates, or monitor the response to marketing campaigns.
Please refer to the Worldpay eComm Reporting and Analytics User Guide.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

27
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.9 Fraud Toolkit

Just because a credit card network/company returns a valid authorization for a purchase does not always
mean that completing the transaction is in your best interest. There are multiple reasons you may wish to
decline a sale on a particular card at a particular time. In many cases there are indicators that the
transaction could be or likely is fraudulent. Acting to stop these transactions at submission prevents loss,
as well as reducing the number fraud related chargebacks in the future. Worldpay offers a robust fraud
solution, the Fraud Toolkit, to assist you in reducing the number of possibly fraudulent transactions
inflicted upon you by bad actors.
The Fraud Toolkit has three tiers or levels of implementation, each providing more rigorous examination
of transaction properties and data points, as well as valuable information and guidance. The table below
provide an overview of the tool provided at each level. The items highlighted in blue require the inclusion
of a small snippet of code on your checkout page.

TABLE 1-8 Fraud Toolkit Implementation Levels

Filter/Feature Essential Extended Premium

AVS Filter X X X

CVV No-Match Filter X X X

International BIN Filter X X X

Prepaid Non-Reloadable Filter X X X

Prior Chargeback Filter X X X

Prior Fraud Advice Filter X X X

Card Velocity Filter (Approved or Attempted) X X X

Email Velocity Filter X X X

Phone Velocity Filter X X X

IP Velocity Filter X X X

Device Velocity Filter X X X

IP Address, Geolocation, and Proxy Detection X X

Merchant Customizable Rules Template X X

ThreatMetrix Cybercrime Dashboard X X

(Asynch) Transaction Review Queues X X

Rule Management and Portal Training X X

Standalone Transaction API Access X X

Cybercrime Industry Report (Quarterly) X X

Access to Fraud Consultant X

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

28
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.9.1 Essential Tier

The Essential tier includes a suite of eleven Fraud Filters that you can apply individually or in
combination. Nine of the eleven filters, based on card/submitted data, potentially require no additional
integration on your part, assuming you already submit the necessary information. The remaining two
filters require you to add a a small snippet of code on your checkout page.

NOTE: Technically, you can make use of the IP Velocity filter without integrating the code snippet
on your checkout page. Instead you can simply include the originating IP Address that you detect in
your transaction by submitting it as a customAttribute. Please note that this method will likely be
less effective than making use of the ThreatMetrix functionality, which includes IP piercing to
determine the true IP of the consumer’s device.

1.9.1.1 Prepaid Card Filtering

Many merchants engaged in recurring payment, installment payment, or deferred billing experience some
loss due to fraud schemes that make use of prepaid cards. Consider the case of a consumer using a
prepaid card with a balance of $100 to make a purchase that involves an initial charge of $50 followed by
three installments of $50 each. The authorization would be approved for the initial transaction, and the
card might have adequate balance for an additional charge, but if the consumer was attempting to
defraud the merchant or simply used the card for other purchases, the card may not have sufficient
balance for any additional payments. While the Prepaid Indicator feature provides you with the
information necessary to make a decision at the time of the sale, and to request a secondary or different
payment method, instead you may wish to have Worldpay filter these transactions automatically when
you send the Authorization transaction.
If you elect to use the Prepaid Card Filtering Service, you can select one of two methods of
implementation. Using the first filtering method, our system declines all Authorization and Sale
transactions when the consumer uses a prepaid card. Upon a decline, the system returns a Response
Reason Code of 309 - Restricted Card - Prepaid Card Filtering Service. This method also allows you
to disable the filtering logic on a transactional basis by including the <prepaid> element set to a value of
false, allowing you to accept any prepaid card for these transactions.
The second method of implementing the Prepaid Card Filtering Service is per transaction. To enable the
filter on a particular transaction, set the <prepaid> element to a value of true. This method is useful to a
merchant who offers products with both one-time payments and installment payments. For products
involving a single payment, you may want to allow the use of prepaid cards, while for the product with
multiple payments you may want to filter prepaid cards.

NOTE: Within either implementation method, you can elect to filter all prepaid cards, or only
non-reloadable prepaid cards. Please speak to your Implementation Consultant for additional
information about setting these global parameters.

1.9.1.2 International BIN Filtering

An examination of your historical fraud data may show a high percentage of fraudulent transactions
originating with certain international cards. You can limit your exposure to this type of fraud by taking
advantage of the International Card Filtering Service. This feature allows you to filter Mastercard and Visa
cards originating in either all foreign countries or selected foreign countries based upon the country of the
card issuer.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

29
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

If you elect to use this feature, when you submit an Authorization/Sale transaction, the system determines
the country of origin of the card. If the card originates outside the United States and you have elected to
filter all international cards, the system declines the transaction. Likewise, if you have elected to filter a
specific country or countries and the card originates from a designated country, the system declines the
transaction. Upon a decline, the system returns a Response Reason Code of 312 - Restricted Card -
International Card Filtering Service.
You can override your settings on a transactional basis by including the <international> element set
to false when you submit the Authorization/Sale transaction. In this case, the system ignores the filtering
service and processes the transaction normally.

1.9.1.3 Prior Chargeback Filtering

If you elect to use the Chargeback Filter Service, there are two configuration options. You can elect to
filter all transactions using a card for which you received a chargeback, or you can elect to filter only the
subset of transactions for which you received a fraud related chargeback (determine by the associated
chargeback reason code). In both cases, the system checks your historical data to see if you received an
applicable chargeback from the same account within the last 90 days. Upon a decline, the system returns
a Response Reason Code of 308 - Restricted Card - Chargeback.

1.9.1.4 Security Code No-Match Filter

The Card brands added the 3- or 4-digit security code to act as a verification that the person ordering your
product in a card-not-present environment has physical possession of the card. While this validation can
be a useful anti-fraud tool, typically, many issuing banks do not decline the transaction based upon a
failure to match the security code. Declining the transaction is left to the discretion of the merchant.

NOTE: Since American Express declines the transaction when the security code does not match,
the Security Code No-Match filter does not apply to American Express transactions. Transactions
declined by American Express for a failure to match the security code use the Response Reason
Code of 352 - Decline CVV2/CID Fail.
Similarly, if Visa, Mastercard, or Discover decline a transaction based upon the security code
results, Worldpay does not apply the filter and the transaction response contains the 352 Reason
Code.

If you elect to use the Security Code No-Match Filter Service, the system takes action only if the issuer
approves the submitted authorization/sale transaction, but includes a no-match code for the
CVV2/CVC2/CID card validation check. In this case, the Worldpay declines the transaction with a
Response Reason Code of 358 - Restricted by due to security code mismatch. The system also
issues an Auth Reversal transaction on your behalf to remove the funds hold on the account.

1.9.1.5 Card Velocity Filtering

Often, when a person attempts to use a stolen credit card successfully, they will follow the initial purchase
with a number of additional purchases within a short period of time. If you elect to use the Fraud Velocity
Filter, the system filters the transaction based upon the number of previously approved Auth/Sale
transactions plus the number of Auth/Sale transactions declined by another filter, for the same account

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

30
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

within a designated time period. Both the total number of transactions and the time period are configured
in the Worldpay Merchant Profile.
Upon a decline, the system returns a Response Reason Code of 315 - Restricted Card - Auth Fraud
Velocity Filtering Service.

1.9.1.6 Prior Fraud Advice Filtering

Worldpay maintains a database of Fraud Advice information received from the Visa and Mastercard
networks for transactions you processed in the last 200 days. If you use the Prior Fraud Advice Filter, the
system compares the account information from the new transaction against the database of accounts with
prior Fraud Advice and filters the transaction if there is a match.
Upon a decline, the system returns a Response Reason Code of 318 - Restricted Card - Auth Fraud
Advice Filtering Service.

1.9.1.7 AVS Filter

One of the fraud prevention tools provided by all card networks is an Address Verification System. By
submitting the customer’s address information in the billToAddress section of the cnpAPI message,
you can verify that the address/zip code supplied by the consumer matches the issuer’s records. The card
networks, however, do not decline transactions based upon the failure to match the address or zip code.
Using the AVS Filter, you can filter potentially fraudulent transactions based upon failure to match any of
the following:
• the address
• the zip/postal code
• the address + zip/postal code (ANDed)
• the address or zip/postal code (ORed).
Upon a decline, the system returns a Response Reason Code of 319 - Restricted Card - Fraud AVS
Filtering Service.

1.9.1.8 Email Velocity Filter

Often, card testers or other bad actors submit a number of transaction using multiple cards, but with a
common email address. The only requirement to make use of this filter is that you collect and include the
consumer’s email address with each transaction. We communicate the email address to our fraud
partner, ThreatMetrix, who tracks and analyzes the information. If the filter detects the same email used in
the configured number of transactions within the configured period of time, the system declines new
transactions (using the same email) on your behalf and returns Response Code 550 - Restricted Device
or IP - ThreatMetrix Fraud Score Below Threshold.

1.9.1.9 Phone Velocity Filter

Similar to email, card testers or other bad actors often submit a number of transaction using multiple
cards, but with a common phone number. The only requirement to make use of this filter is that you
collect and include the consumer’s phone number with each transaction. We communicate the phone
number to our fraud partner, ThreatMetrix, who tracks and analyzes the information. If the filter detects

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

31
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

the same phone number used in the configured number of transactions within the configured period of
time, the system declines new transactions (using the same email) on your behalf and returns Response
Code 550 - Restricted Device or IP - ThreatMetrix Fraud Score Below Threshold.

1.9.1.10 IP Velocity Filter

The IP Velocity filter is one of the two filter in the Essential tier that requires (see note below) the addition
of a code snippet to your checkout page. This snippet, which you also need to implement for the higher
tiers of Fraud Toolkit, allows our partner, ThreatMetrix, to perform IP interrogation/piercing t determine the
true IP Address of the device originating the order. As with the other velocity filters, if the filter detects the
same IP Address used in the configured number of transactions within the configured period of time, the
system declines new transactions from the same IP Address on your behalf and returns Response Code
550 - Restricted Device or IP - ThreatMetrix Fraud Score Below Threshold.

NOTE: Technically, you can make use of the IP Velocity filter without integrating the code snippet
on your checkout page. Instead you can simply include the originating IP Address that you detect in
your transaction. Please note that this method will likely be less effective than making use of the
ThreatMetrix functionality, which includes IP piercing to determine the true IP of the consumer’s
device.

1.9.1.11 Device Velocity Filter

The Device Velocity filter is the second Essential tier filter in the that requires the addition of a code
snippet to your checkout page. In this case, the snippet allows ThreatMetrix to construct a device
fingerprint of the system originating the order. As with the other velocity filters, if the filter detects the
same device used in the configured number of transactions within the configured period of time, the
system declines new transactions from the same device on your behalf and returns Response Code 550 -
Restricted Device or IP - ThreatMetrix Fraud Score Below Threshold.

1.9.1.12 Application of Filters - Filtering Rules

NOTE: Filter Rules are defined as part of your Merchant Profile. Please consult with your
Relationship Manager and/or your Implementation Consultant concerning the provisioning of Filter
Rules.

While you can have all submitted transactions flow through the Fraud toolkit, you likely want to exercise a
finer control over the application of the filters based upon a particular product, service or other criteria.
The system provides you the flexibility of restricting which transactions are submitted to the filtering
service and which filters the system applies to which groups. This is accomplished by defining Filtering
Rules.
For each Filtering Rule you first define a subgroup of transactions by selecting one of the following Flow
Selectors: Report Group, Billing Descriptor, orderSource, or MID (for Payment Facilitators, flow control by
MID or order source only). Only one selector can be applied per rule. After selecting a particular Flow
Selector, you then select which filters to have applied to that subset of transactions. You can define the
Filter Rules so that filters are ORed (transaction filtered when any one of the filters conditions met), or
ANDed (transaction filtered when multiple filter conditions met). Table 1-9 defines five rules that a
merchant might define.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

32
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-9 Example - Fraud Filtering Service Rules

Filter Flow Selector Filters

1 Report Group = "XYZ" Prepaid

2 Report Group = "XYZ" International

3 orderSource = "recurring" Prepaid + Prior Chargeback

4 orderSource = "ecommerce" Card Velocity + Security Code No-match

5 Billing Descriptor = "GoldMember" Prepaid + International

Table 1-9 defines five Filter Rules that a merchant might use. These rules would be applied as follows:
• Filters 1 and 2 apply to the subset of transactions that are members of Report Group XYZ and use
the Prepaid and International Filters. Since the Filter Rules are defined separately, the rules are
ORed. So, if a transaction uses either a Prepaid card or a card of International origin, the filtering
occurs.
• Filter 3 applies to the subset of transactions that have an orderSource value set to recurring. Filtering
occurs only if both the criteria for the Prepaid Filter AND the Prior Chargeback Filter are met.
• Filter 4 applies to the subset of transactions that have an orderSource value set to ecommerce.
Filtering occurs only if both the criteria for the Card Velocity Filter AND the Security Code No-Match
Filter are met.
• Filter 5 applies to the subset of transactions that have an Billing Descriptor value set to GoldMember.
Filtering occurs only if both the criteria for the Prepaid Filter AND the International Filter are met.

1.9.2 Extended Tier

The Extended Tier include all of the Essential Tier filters, but offers an additional levels of fraud detection
made available through Worldpay’s partnership with ThreatMetrix. The addition of the same code snippet
used for the IP and Device Velocity filters to your checkout page allows ThreatMetrix to gather additional
data points, such as the consumer’s device, proxy use, and location. Unlike the filters in the Essential
Tier, which are basic accept/decline filters, the Extended Tier takes the data and compares the
information to a rule list. Worldpay supplies an initial, Best Practices rules list designed for your business
type (i.e., Retail, Digital, Non-profit, etc.), which you can modify and refine for you particular business
model. Each rule, when triggered, add or subtract a preset value from the transaction score. If the score
fall below a set threshold, the system declines the transaction, unless you prefer to make the final
decision yourself. In either case, Worldpay returns the score and a list of triggered rules in the transaction
response message.
In addition to the ThreatMetrix rules engine, you get access to the ThreatMetrix Portal allowing you to
customize your rules list and scoring values. This level also allows you to white list/black list items, such
as email addresses and phone numbers. Other items included in this tier are:
• ThreatMetrix Cybercrime Dashboard
• Asynchronous Transaction Review Queues
• Monthly Rules and Portal training
• API Access to Standalone Fraudcheck transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

33
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.9.3 Premium Tier

The Premium Tier provides all of the tools from the Essential and Extended Tiers, and most importantly,
access to the Worldpay eComm Fraud Consulting service. With the service, the Fraud Consultant
assigned to you helps analyze your transactional data, recommend rule changes to fine-tune your results,
and advises you on fraud detection strategy.

1.9.4 Modifications to Your Web Page

For ThreatMetrix to gather information for analysis, you must add certain profiling tags (see example
below) to selected pages served by you web application. These tags allow ThreatMetrix to collect
information by loading objects used for detection into the consumer’s browser. These tags are invisible to
the consumer and add only a fraction of a second to your page’s rendering time. Once loaded, these
objects require only 3-5 seconds to gather profiling information from the consumer device.
Place the tags as early as possible on the page, inside the <body></body> tags of the page HTML.

Example: ThreatMetrix Profiling Tags

NOTE: Replace UNIQUE_SESSION_ID with a uniquely generated handle that includes the
Worldpay supplied prefix.
The value for ORG-ID is a Worldpay supplied value.
The pageid tag is not used at this time. The value for PAGE-ID defaults to 1.
For production, replace h.online-metrix.net with a local URL and configure your web server to
redirect to h.online-metrix.net.

<!-- Begin ThreatMetrix profiling tags below -->

<script type="text/javascript"
src="https://h.online-metrix.net/fp/tags.js?org_id=ORG_ID&session_id=UNIQUE_SESSION_ID&
pageid=PAGE_ID"></script>
<noscript>
<iframe style="width: 100px; height: 100px; border: 0; position: absolute; top:
-5000px;"
src="https://h.online-metrix.net/tags?org_id=ORG_ID&session_id=UNIQUE_SESSION_ID&pageid
=PAGE_ID"></iframe>
</noscript>
<!-- End profiling tags -->

1.9.4.1 cnpAPI Transactions

To subject a transaction to the advanced fraud checks performed and retrieve the results, you simply
submit the <webSessionId> element as part of your cnpAPI Authorization (or Sale) transaction. This
session Id is the same unique value you assigned and sent to ThreatMetrix when your web page called
the application (designated as UNIQUE_SESSION_ID in the ThreatMetrix Profiling Tags example). When
we receive an Authorization/Sale that includes the <webSessionId>, our system automatically queries
the ThreatMetrix platform for the associated results. The cnpAPI response message includes the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

34
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

<advancedFraudResults> element containing the score and status and information about any
triggered rules. The following two examples show a standard Authorization transaction, including a
<webSessionId> and a pass response.

Example: Authorization including <webSessionId> Element

<cnpOnlineRequest version="12.3" xmlns="http://www.vantivcnp.com/schema"
merchantId="81601">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<authorization id="002" reportGroup="001601">
<orderId>10102013_sessionId_app</orderId>
<amount>1002</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</billToAddress>
<card>
<type>MC</type>
<number>5405102001000003</number>
<expDate>1115</expDate>
</card>
<advancedFraudChecks>
<webSessionId>ASDFG-AXXXXAB999</webSessionId>
</advancedFraudChecks>
</authorization>
</cnpOnlineRequest>

Example: Authorization Response including <advancedFraudResults> Element

<cnpOnlineResponse version="12.3" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<authorizationResponse id="002" reportGroup="001601">
<cnpTxnId>82823534116454639</cnpTxnId>
<orderId>10102013_sessionId_app</orderId>
<response>000</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

35
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

<responseTime>2018-05-08T21:36:50</responseTime>
<postDate>2017-03-08</postDate>
<message>Approved</message>
<authCode>000003</authCode>
<fraudResult>
<avsResult>00</avsResult>
<advancedFraudResults>
<deviceReviewStatus>pass</deviceReviewStatus>
<deviceReputationScore>50</deviceReputationScore>
<triggeredRule>FlashImagesCookiesDisabled</triggeredRule>
</advancedFraudResults>
</fraudResult>
</authorizationResponse>
</cnpOnlineResponse>

NOTE: The other possible values for the <deviceReviewStatus> element are fail, review,
unavailable, and invalid_session.
The <deviceReputationScore> value can range from -100 to 100. The resulting pass, fail, or
review value depends upon your profile settings.
The <triggeredRule> element can occur multiple times, once for each rule triggered.

1.9.4.2 Information Only Option

If you wish to retain full control of the decision to accept or decline transactions, Worldpay offers the
option of using the Advanced Fraud Tools in an Information Only mode. In this configuration, you receive
the same information in the response as you would with the full implementation; however, Worldpay will
not decline transactions with a failing score automatically.
If the authorization is declined by the network, you can choose to recycle the transaction or do nothing. If
an authorization with a failing score receives approval from the network, it would be up to you to reverse
the authorization should you decide not to proceed with the transaction. This is similar to the case of an
approved transaction that has a status of Review, but you decide not to proceed. Issuing an authorization
reversal allows you to avoid any misuse of Auth fees otherwise imposed by the card networks.

1.9.4.3 Fraud Check Transactions

If you wish to retrieve the Advanced Fraud results without introducing a Authorization or Sale
transactions, use a Fraud Check transaction (see Fraud Check Transaction on page 274). The
standalone Fraud Check also allows you to check various types of account takeover and new account
creation fraud. By submitting the <eventType> element, with or without the <accountLogin>,
<accountPasshash>, and other information, you can check for the following scenarios:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

36
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

<eventType> Scenario Description

account_creation Checks for evidence of new account creation fraud. We
recommend you include the <accountLogin> element.
detail_changes Checks for evidence of account takeover fraud, such as
changes to billing address and other customer profile
information. We recommend you include the
<accountLogin> element, along with billing information and
the <accountPasshash> element for password changes.
login Checks for evidence of account takeover/hacking fraud. We
recommend you include the <accountLogin> and
<accountPasshash> elements.

payment (default) Checks for evidence of traditional payment fraud. We

recommend you include the <accountLogin> element.

You can only submit Fraud Check transactions as Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

37
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.10 Tokenization Feature

Tokenization is the process by which a reference number, referred to as a token, replaces a credit card
number or Direct Debit account number. Unlike the card or account number, you can store the token on
your system without concern of a security breach exposing critical customer information. Instead,
Worldpay stores the information in a secure vault and accesses it only when you submit a transaction
using the supplied token.

NOTE: You must be enabled for card tokenization to use the Direct Debit tokenization feature.

In the case of credit cards, since you do not store the customer’s account information, the scope of PCI
requirements to which you must comply may be minimized. This may greatly reduce the cost of
compliance and may limit your liability in the event of a breach. You can reduce the requirements further,
as well as the possibility of exposure from a breach, through the use of the Worldpay eProtect. By
sending the card information from your checkout page directly to our systems you eliminate one more
facet of handling the card information.

NOTE: Worldpay recommends you consult your own PCI Compliance and Legal departments to
determine the specific advantages of tokenization for your company.

This section discusses the following topics:

• How Tokenization Works
• Token Formats
• Obtaining Tokens
• Supported Token Transactions

NOTE: Please refer to the Worldpay eComm eProtect Integration Guide for additional
information about the use of and integration to the Worldpay eProtect value added service.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

38
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.10.1 How Tokenization Works

In a non-tokenized environment, multiple parties handle and store customer data, including the
card/Direct Debit account number, for each transaction. From a merchant standpoint, they receive the
information, store it in their own database, and transmit it to their processor with the transaction request,
as shown in Figure 1-5 for card information. While the access and transmission of the data may occur a
single time, as in the case of a Sale transaction, frequently data transmission occurs multiple times in
order to complete a single sale, as in the case of an Auth followed by a Capture or several partial
Captures. The local storage and repeated transmission of the information creates additional possible
breach points, where a malicious third party could compromise the information.

FIGURE 1-5 Card Information Flow in Non-Token Environment

Card Assn. Issuing Bank

Merchant

Account # Account # Account # Account #

Cardholder

Account # Account # Account # Account #

Database Database Database Database

In a tokenized environment transmission of customer data ideally occurs a single time and the merchant
never stores it locally, as shown in Figure 1-6 for card data. Once account number registration occurs,
using either a registerTokenRequest or by submitting the account number (or low value token, when
using eProtect) with any supported transaction, Worldpay returns a (high value) token. You store the
token locally and use it for all future transactions concerning that account. Worldpay takes responsibility
for storing and safeguarding the account information.

NOTE: The difference between card data flow and Direct Debit data flow is that the entities
upstream of Worldpay are different. The operation remains the same from a merchant standpoint.

FIGURE 1-6 Card Information Flow in Tokenized Environment

NOTE: The use of eProtect allow the account information to come directly to Worldpay, so you only
handle the token.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

39
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.10.2 Token Formats

Worldpay supports both High-Value and Low-Value tokens, designed to address specific payment
processing operations. Both token types replace sensitive data, though the generated token values differ
based on specific domain and transaction controls.
We generate High-Value tokens statically, replacing PANs with a consistent surrogate value each time
you present the same PAN for tokenization. PCI DSS Tokenization Guidelines 2.0 (2011) defines a
High-Value as a token usable as a payment instrument to perform a payment transaction. Worldpay
OmniToken is an example of a High-Value token. The generation of a Worldpay OmniToken is
card-based, embodying a one-to-one correlation with the PAN it replaces, and does not expire unless the
PAN is no longer valid with the card issuer.
PAN to OmniToken pairing is unique to a given organization, and is channel and platform agnostic. This
means the same token value persists across the entire merchant payment processing environment, but
does not persist across different merchant organizations. For example, Table 1-10 shows the same PAN
submitted for three different transactions. The first two transactions involve the same merchant with one
transaction from a Point of Sale terminal and one Online. Since these transactions use the same PAN
and come from the same merchant, they use a common Worldpay OmniToken. The third transaction,
from a different merchant results in the generation of a different OmniToken even though it is the same
PAN.

TABLE 1-10 OmniToken Generation for Common PAN Across different Channels and Merchants

Merchant PAN Worldpay OmniToken

Merchant A - POS 4418 3789 1620 3675 4418 3711 2222 3675

Merchant A - Online 4418 3789 1620 3675 4418 3711 2222 3675

Merchant B - Online 4418 3789 1620 3675 4418 3724 9587 3675

NOTE: The OmniToken shown in the example above make use of the Informative token format,
which preserves the first-6 and last-4 digits.

Generated dynamically, Low-Value tokens have a unique value for each transaction, even if you submit
the same PAN for tokenization multiple times. Low-value tokens utilize additional compensating controls,
such that the token applies only to specific transactions and processing environments. The Worldpay
eProtect RegistrationID is an example of a Low-Value token used for initial data capture of payment card
data in ecommerce and mobile environments. Worldpay eProtect RegistrationID is a transaction-based
token value requested through a low-trust environment over the Internet. The token value is valid only for
24-hours, after which you can no longer use it for payment processing.
There are various attributes, including the length, format and character set, that define the structure of the
card numbers and the tokens that replaces them. For example, all PAN values regardless of length,
conform to the Luhn MOD10 algorithm. Worldpay supports several token format options to meet your
implementation needs. These token formats, while always using the same character set as PANs, range
from a completely random, fixed-length number to a format preserving token that reuses the first-6 and
last-four digits of the PAN. In addition, with the exception of the legacy eComm token version, each token
format is available in either a MOD10 or a MOD10+1 format. The MOD10+1 format allows you to more
easily distinguish a real PAN from a token.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

40
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

NOTE: The Worldpay eComm Legacy token is only available in a MOD10+1 conforming format.

The table below provides information about the various OmniToken formats available for credit cards.
Since you cannot intermix token formats within a Token Group and your entire organization may be a
single Token Group, you should carefully select the format that best meets your needs. When selecting a
format, you should consider if you need access to the IIN (Issuer Identification Number; formerly known
as BIN), as well as whether you need the last-four digits of the PAN.

TABLE 1-11 High-Value Credit Card Tokens

Format-Preserved Digits
Name MOD10 Option
First-Six
(IIN) Middle Last-Four

Informative A1 6 Random 4 MOD10+1

Informative A 6 Random 4 MOD10

Last 4 Preserved 1 Random Random 4 MOD10+1

Last 4 Preserved Random Random 4 MOD10

Complete Random 1 Random Random Random MOD10+1

Complete Random Random Random Random MOD10

Minimum 16A 1 6 Random 4 MOD10+1

Minimum 16A 6 Random 4 MOD10

Existing Worldpay eComm Merchants 1 Random* Random 4 MOD10+1

* First-six returned in the <bin> element of the response message

TABLE 1-12 Low-Value Tokens

Format Name Format-Preserved MOD10 Option

Code Digits

N/A RegistrationID None MOD10+1

N/A Checkout Id None MOD10+1

1.10.2.1 High Value Token Data Format Summary

This section provides additional information about the various Worldpay OmniToken formats. In all
examples the randomly generated portion of the token is shown in green.

Informative A and Informative A1

This token format duplicates the length of the original PAN and preserves both the first-six and the
last-four digits of the original PAN. The Informative A version is MOD10 compliant, while the Informative
A1 version is MOD10+1 compliant.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

41
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Example: Informative A and A1 Formats

Original PAN Value 4418 3789 1620 3675

Tokenized Value 4418 3711 2222 3675

Last 4 Preserved and Last 4 Preserved 1

This token format duplicates the length of the original PAN and only the last-four digits of the original
PAN. The Last 4 Preserved version is MOD10 compliant, while the Last 4 Preserved 1 version is
MOD10+1 compliant.

Example: Last 4 Preserved and Last 4 Preserved 1 Formats

Original PAN Value 4418 3789 1620 3675

Tokenized Value 3938 7311 2222 3675

Completely Random and Completely Random 1

This token format duplicates the length of the original PAN, but does not preserve any portion of the
original PAN. The system generates all digits randomly, except the checksum (last) digit, which the
system set to make the overall token either MOD10 or MOD10+1 compliant. The Completely Random
version is MOD10 compliant, while the Completely Random 1 version is MOD10+1 compliant.

Example: Completely Random and Completely Random 1 Formats

Original PAN Value 4418 3789 1620 3675

Tokenized Value 3938 7311 2222 2871

Minimum 16A and Minimum 16A 1

This token format returns a token with a length of sixteen digits or greater depending upon the length of
the original PAN, while always preserving the first-six digits and the last-four digits. If the PAN is sixteen
digits, the resulting token would be identical to the corresponding Informative format. If the PAN is less
than sixteen digits, the resulting token adds random digits in the middle to bring the total to sixteen. If the
PAN is greater than sixteen digits, the resulting token preserves the length, replacing the middles digits
with random numbers. The Minimum 16A version is MOD10 compliant, while the Minimum 16A 1 version
is MOD10+1 compliant.

Example: Minimum 16A and Minimum 16A 1 Formats

Original PAN Value 4418 37891 3675 4418 37891556438 3675

Tokenized Value 4418 3711 2222 3675 4418 3711 2222643 3675

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

42
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Worldpay eComm Merchant A

This token format duplicates the length of the original PAN and preserves the last-four digits of the
original PAN. The first-six digits of the PAN are returned in a separate element of the XML response
message. The eComm Merchant A version is MOD10+1 compliant.

Example: eComm Merchant A

Original PAN Value 4418 3789 1620 3675

Tokenized Value 2875 3711 2222 3675

NOTE: Only existing eComm merchants using the Vault tokenization service can use the Comm
Merchant A form. Other merchants requiring this format should use the Last 4 Preserved 1 token
format.

Direct Debit Token Format

You can also receive tokens for Direct Debit account information. The generated token represents the
routing and account numbers. Direct Debit tokens are randomly generated, always 17 characters in
length, and MOD10 + 1 compliant. We return the last three digits of the account number in the
<eCheckAccountSuffix> element.

Original Direct Debit Info Account Type: Checking

Route/Transit: 123456789
Account Number: 123456789ABCDEFGH

Tokenized Value 22590305509028340

1.10.2.2 Low Value Token Summary

eProtect Registration ID
The eProtect RegistrationID is a Low-Value token that are merchant specific, dynamically generated, and
unique to each transaction. Each token is 19 digits (numeric) long, MOD10+1 compliant, with no format
preservation, and a lifespan of 24 hours. The eProtect RegistrationID can work in conjunction with any
OmniToken format.

Example: Registration ID

Original PAN Value 4872 3789 1620 3675

Tokenized Value 9857125845785587

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

43
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

eProtect Checkout Id
The eProtect Checkout ID is a Low-Value token dynamically generated, and uniquely assigned to each
capture of the Card Security Code (CVC, CVV2) for eCommerce customer verification use cases such as
card on file where the merchant has in possession of a Worldpay High-Value token. Each token is 18
digits (numeric) long, MOD10+1 compliant, with no format preservation, and a lifespan of 24 hours. The
eProtect Checkout ID can work in conjunction with any OmniToken format.

Example: Checkout ID

Original Card Security Code 123

Tokenized Value 585471254789632587

1.10.3 Obtaining Tokens

NOTE: You must be token enabled and certified prior to using the feature. Please consult your
Relationship Manager concerning the requirements and details of this process.

There are three ways for you to obtain tokens for account numbers. First, you can submit an existing card
number/Direct Debit account information (account number and routing number) using a Register Token
request. When Worldpay receives this transaction type, we generate a token and return it to you via a
Register Token response (see Register Token Transactions on page 292.) Although you can use this
method to tokenize an account number at any time, it is most useful when initially tokenizing your
customer database. Worldpay recommends that you collect all distinct credit card numbers in your
database and submit the information in one or more large Batch files. When you receive the response file,
parse the returned token information to your database, replacing the card numbers.
The second method involves submitting a supported transaction with the card information. If you are a
tokenized merchant, Worldpay automatically converts the card number to a token and returns the token in
the response message. Typically, you would use this method when taking and submitting a transaction
during the normal course of business. When you receive the response, you store the token instead of the
card information.

NOTE: Once we convert a card number to a token for a particular merchant, subsequent
submissions of the same card number return the same token.

The third method of obtaining a token applies only to merchants using the Worldpay eProtect feature. In
this case, upon submission of an account number via the eProtect API, Worldpay issues a low value
token called a Registration Id. You then submit the Registration Id in an Authorization or Sale transaction
and receive the token in the response message.

1.10.3.1 Bulk Token Registration

If you are new to Worldpay, and have utilized tokens with a previous processor, Worldpay can perform a
bulk token registration on all the card numbers that were vaulted with your previous processor. The
following is an example of the process:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

44
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1. During your implementation with Worldpay, you contact your previous processor and request an
encrypted mapping file containing the card and token numbers for your customers. A Implementation
Consultant will work with you and your previous processor to facilitate the secure transfer of this file
without impacting your PCI compliance. The file can be comma-delimited, tab-delimited, or any other
common format.
2. Worldpay performs a bulk token registration of all of the card numbers contained in the file.
3. Worldpay returns a mapping file to your organization containing the old tokens and the new
Worldpay-issued tokens, so that you can update your order processing system.
Note that Worldpay supports token-extractor formats of all major token service providers. Contact your
Implementation Consultant for more information or to initiate this process.

1.10.4 Supported Token Transactions

The following transactions support the generation and use of tokens:
• Authorization - You can submit the transaction either with a token or card information. If you submit
card information, Worldpay automatically generates the token and returns it in the response.
• Capture Given Auth - You can submit the transaction either with a token or card information. If you
submit card information, Worldpay automatically generates the token and returns it in the response.
• Credit - You can submit the transaction either with a token or card information. If you submit card
information, Worldpay automatically generates the token and returns it in the response.
• Force Capture - You can submit the transaction either with a token or card information. If you submit
card information, Worldpay automatically generates the token and returns it in the response.
• Register Token - You use this transaction to convert a card number or Direct Debit account number
to a Worldpay token without an associated authorization, verification or payment transaction.
• Sale - You can submit the transaction either with a token or card information. If you submit card
information, Worldpay automatically generates the token and returns it in the response.
• eCheck Credit - You can submit the transaction either with a token or account information. If you
submit account information, Worldpay automatically generates the token and returns it in the
response.
• eCheck Redeposit - You can submit the transaction either with a token or account information. If you
submit account information, Worldpay automatically generates the token and returns it in the
response.
• eCheck Sale - You can submit the transaction either with a token or account information. If you
submit account information, Worldpay automatically generates the token and returns it in the
response.
• eCheck Verification - You can submit the transaction either with a token or account information. If
you submit account information, Worldpay automatically generates the token and returns it in the
response.
• Update Card Validation Number - This is a special transaction type provided to allow the update of
a CVV2/CVC2/CID code supplied at the time of the token registration. You should only use this
transaction type if you had previously submitted the account number and security code in a
registerTokenRequest transaction and now need to change the CVV2/CVC2/CID value.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

45
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.10.5 Compliance with Visa Best Practices for Tokenization

As shown below, the Worldpay tokenization solution complies with 11 of the 12 items listed in the Visa
Best Practices for Tokenization document. The twelfth item concerns the management of stored historical
data (that may contain card information) within your systems. Tokenizing all historical card info when
implementing the Worldpay solution would satisfy this item, as would protecting it per PCI DSS
requirements.

TABLE 1-13 Visa Best Practices for Tokenization Compliance

Item # Who Domain Best Practice Complies?

1 Worldpay Tokenization System Network Segmentation Yes

2 Worldpay Tokenization System Authentication Yes

3 Worldpay Tokenization System Monitoring Yes

4 Worldpay Tokenization System Token Distinguishability Yes

5 Worldpay Token Generation Token Generation Yes

6 Worldpay Token Generation Single- vs. Multi- use Tokens Yes

7 Worldpay Token Mapping PAN Processing Yes

8 Worldpay Card Data Vault PAN Encrypted in Storage Yes

9 Worldpay Card Data Vault Covered by PCI DSS Yes

10 Worldpay Cryptographic Keys Key Strength Yes

11 Worldpay Cryptographic Keys Covered by PCI DSS Yes

12 Merchant Historical Data Non-tokenized data protected Merchant

Management Implementation
Decision

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

46
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.11 Direct Debit Processing

A Direct Debit is an alternative payment method that directly debits a consumer's account via the
Automatic Clearing House (ACH) network in the US or the Electronic Funds Transfer (EFT) service in
Canada. From a merchant’s standpoint offering Direct Debit as a payment method has several
advantages, including a large consumer base in excess of 130 million accounts in the United States and
no interchange fees.
This section provides information about several Worldpay Direct Debit processing features. Please
consult with your Relationship Manager for additional information.

NOTE: Worldpay also supports Direct Debit processing for our merchants doing business in
Canada. We support all Direct Debit transaction types, except Verification and Prenotification
transaction. Please consult your Relationship Manager for additional information.

1.11.1 Validation Feature

Worldpay performs a validation of the Direct Debit routing number. This is done both to verify that the
routing number is correctly formatted and that it exists in the Fed database. If the routing number fails this
validation, the transaction is rejected. Worldpay performs this validation on all Direct Debit transactions
automatically.

1.11.2 Verification Feature

Since Direct Debits do not have an associated authorization process, allowing you to confirm the
availability of funds and hold the purchase amount, there is a higher risk of certain types of fraud. The
optional eCheck Verification transaction allows you to submit a Direct Debit account number for
comparison to a database containing historical information about the account, as well as the account
holder. When you submit an eCheck Verification transaction the information you provide is compared to a
negative database to see if the account is associated with activities, such as fraud, over drafts, or other
items determined to be risk factors.

NOTE: Worldpay makes use of a third party service, Certegy Check Services Inc., for all verification
operations.
The verification service is not supported for Canadian Direct Debits.
The verification service is not available for Payment Facilitators.

You can also initiate an account verification operation as part of an eCheck Sale transaction by setting the
<verify> element to true. In this case, the eCheck Sale transaction is conditional upon the verification
passing. If the verification fails, the sale is not processed.

1.11.2.1 Required Contents of Decline Notice

In the event you elect to perform verification on a transaction and also elect not to proceed with the
transaction based upon a verification failure, you must provide your customer with the following Decline

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

47
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

Notice. You can provide the notice orally, electronically, via e-mail, and/or via U.S Mail, depending upon
the type of transaction. The notice must be substantially as the notice set forth below that contains the
disclosures required under the Fair Credit Reporting Act and instructs your customer how to contact
Certegy directly.

NOTE: If the required language of the Decline Notice changes, Worldpay notifies you of the
change. You must enact the changes within 10 days.

Example: Decline Notice

We're sorry, but we are unable to proceed with your transaction. This determination was based on
information provided by Certegy Check Services, Inc. (“Certegy”). To protect your privacy, Certegy
did not provide any financial information to [Client's Name] during the authorization process.
The reason your transaction was not authorized was due to [mark one of the following based on
applicable decline code transmitted by Certegy]:
• account closed
• dishonored check or transfer information contained in Certegy's files
• Certegy had insufficient information available
• the identification information you entered did not conform to established guidelines
You have the right under the Fair Credit Reporting Act to know the information Certegy utilized to
make a determination regarding your check. If you find that any information Certegy utilized in its
decision is inaccurate or incomplete, you have a right to dispute it with Certegy.
You may call Certegy toll free at 800-695-1854, or write to Certegy Check Services, Inc., P.O. Box
30046, Tampa, FL 33680-3046.
If you contact Certegy, please provide the following information so they can respond promptly to your
request:

• First Name • Driver’s License Number & State

• Current Address • Home Telephone Number
• Date Declined • Date of Birth
• Dollar Amount • Social Security Number
• Check/Draft/Transfer Number • Merchant Name
• Checking Account Number • Name of Financial Institution

1.11.3 Automatic Notice of Change (NoC) Updates

Similar to an issuing bank providing credit card Account Updater information, RDFIs provide Notification
of Change (NoC) files and deliver them through the ACH network. These NoCs include updated account
information including bank routing numbers, account numbers, and account names.
Worldpay makes available the NoC information to you for your use in updating your customer files.
Additionally, if you submit a transaction containing information that has changed, we automatically update

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

48
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

the information and forward the corrected transaction to the ACH network. The cnpAPI response
message to you also contains the updated information for your use in correcting your database.

NOTE: While we always make the NoC information available to you, Worldpay does not support
automatic updating of account information for Payment Facilitators.

1.11.4 Auto Redeposit Feature

NACHA rules allow merchants to redeposit entries when the initial deposit was returned for either
Insufficient Funds or Uncollected Funds. Two redeposit attempts are allowed within 180 days of the
settlement date of the initial deposit. Worldpay offers an optional service that allows you to preconfigure
automatic redeposits of transactions returned for the those reasons. You define the number of days from
the initial return for Worldpay to resubmit the transaction. You also define the number of days from the
return of the first resubmission for the attempt of a second resubmission.

NOTE: You track the current state of your transactions, returns, and resubmissions via the iQ User
Interface. Please refer to the iQ Reporting and Analytics User Guide for additional information.

For example, you submitted an eCheck Sale transaction on 29 January that declines for Return Reason
Code R01 - Insufficient Funds. The return occurs on 1 February. With the Auto Redeposit feature enabled
and a preset period of 5 days for the first redeposit, the system automatically generate a resubmission of
the deposit on 6 February. If this transaction also declines for the same reason code on 7 February and
you have a preset time period for the second redeposit of 7 days, the system generates the second
redeposit on 14 February.

1.11.5 eCheck Prenotification

An eCheck Prenotification is a non-monetary transaction used to verify the account information supplied
by the consumer is valid. These transactions are sent to the ACH network to help ensure subsequent
entries are posted appropriately. Since this is a verification of account information, typically, you would
submit a Prenotification transaction in advance of processing the order, during the customer set-up
process. There are two types of Prenotification transaction types: echeckPreNoteCredit and
eCheckPreNoteSale. Per NACHA requirements, you must submit the Prenotification transaction that
corresponds to the intended, subsequent transaction. For example, if you are planning to submit an
echeckSale transaction and want to verify the account information, you should submit a
echeckPreNoteSale.
The possible ACH network responses to a prenotification are as follows:
• No response - applies when the account is open and the account information is correct.
• Notification of Change - provides updated account information, including correct routing number,
e.g. C02 Incorrect routing/transit number (visible in the SSR eCheck NOC report).
• Return code - provides account status, e.g. R02 Account is closed, R03 No account on file, R04
Invalid account number.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

49
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

NOTE: Prenotification transactions are only supported in cnpAPI V9.1 or above and only in Batch
submissions. Prenotification transactions are not supported for Payment Facilitators or for Canadian
Direct Debits.

When you submit either of the Prenotification transaction types, the system sends an acknowledgment in
the Batch response file. This response file does not provide the results of the prenotification check, but
rather a verification that we received the transaction and it was properly formatted. You receive the results
to the check in the SSR eCheck Notification of Change report. This report is run daily and you can expect
to see the results for submitted prenotification checks by the second or third business day after the
settlement day. The settlement day for a Prenotification transaction is defined as the next business day
after submission to the ACH network. Remember, if the account you are attempting to verify is open and
the account information is correct, the report will not contain an entry for that transaction. The report only
contains NOCs (update information).
Per NACHA regulations, you can submit the eCheck Sale or eCheck Credit transaction on the third
business day after the settlement day; however, there might still be a forthcoming NOC on that day. Due
to the timing of the responses from NACHA, the generation of the reports, and the movement of the
transactions, you should wait until the fourth day after the settlement day to submit the live transaction
unless you receive a NOC earlier. This timing is illustrated in the example below.
1. You submit a Prenotification transaction on Monday prior to your cut-off time.
2. Our system forwards the transaction to NACHA on Tuesday. Note, this makes Wednesday the
settlement day.
3. NACHA responds with a NOC/return, if any, by Thursday night.
4. On Friday, the information from NACHA is processed by our systems.
5. On Saturday morning, the SSR NOC report containing the information is available to you.
6. You can submit the eCheck Sale or eCheck Credit transaction before your cut-off time on Saturday
night. This is the fourth day after settlement, the fifth day after submission.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

50
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.12 eCommerce Solution for Apple Pay™

Worldpay supports Apple Pay for in-app and in-store purchases initiated on compatible versions of
iPhone and iPad, as well as purchases from your desktop or mobile website initiated from compatible
versions of iPhone, iPad, Apple Watch, MacBook and iMac (Apple Pay on the Web).
For in-store transactions, a consumer can use the Near Field Communications (NFC) chip in their device
to make a purchase by simply touching the device to an NFC-compliant terminal. Identity verification is
provided by Touch ID, a fingerprint reading application built into the device. If you wish to allow Apple Pay
transactions from your native iOS mobile application, you must build the capability to make secure
purchases using Apple Pay into your mobile application.
If you wish to allow Apple Pay payments on your desktop or mobile website, your website must be
configured to work with Apple to request authorization from the consumers iPhone or iPad via Touch ID.
See Table 1-14, "Apple Pay on the Web Compatible Devices" for more information.
This section provides an overview of the operation of Apple Pay and Apple Pay on the web, along with
the several methods you can use to submit Apple Pay purchases to the Worldpay eCommerce platform.
The topics discussed are:
• Overview of Apple Pay Operation
• Worldpay Decryption of Apple Pay PKPaymentToken
• Merchant Decryption of Apple Pay PKPaymentToken
• Recurring Payments with Apple Pay

1.12.1 Overview of Apple Pay Operation

The operation of Apple Pay and Apple Pay on the web is relatively simple, but will require either the
development of new native iOS applications or the modification of your existing applications or website
that include the use of the Apple PassKit Framework (or Apple Pay JavaScript for Apple Pay web) and
the handling of the encrypted data returned to your application by Apple Pay. The basic steps that occur
when a consumer initiates an Apple Pay purchase using your mobile application or website are:
1. When the consumer selects the Apple Pay option from your application, your application makes use
of the Apple PassKit Framework (or Apple Pay JavaScript) to request payment data from Apple Pay.
2. When Apple Pay receives the call from your application and after the consumer approves the
Payment Sheet (using Touch ID), Apple creates a PKPaymentToken using your public key. Included
in the PKPaymentToken is a network (Visa, Mastercard, Discover, or American Express) payment
token and a cryptogram.
3. Apple Pay returns the Apple PKPaymentToken (defined in Apple documentation; please refer to
https://developer.apple.com/library/archive/documentation/PassKit/Reference/PaymentTokenJSON/P
aymentTokenJSON.html).
The remainder of this section discusses the various options for handling the PKPaymentToken in the
transaction flow.

1.12.2 Worldpay Decryption of Apple Pay PKPaymentToken

Worldpay recommends using one of the Worldpay Decryption methods. This transaction process relieves
you from the burden of creating and maintaining public and private keys, as well as decrypting the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

51
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

PKPaymentToken. If you have already implemented eProtect in a mobile application, you should use
eProtect for Apple Pay. A second, similar method, which still allows you to submit the PKPaymentToken
without decryption, involves you sending the Authorization/Sale transaction with the PKPaymentToken
key values in a new cnpAPI element structure (see applepay), typically from your server. This method can
be used even if you are not tokenized with Worldpay.
In all of these implementations, your Worldpay Implementation Consultant will provide a CSR (Certificate
Signing Request) you use in your registration process with Apple Pay. The CSR provides Apple Pay with
the public key used for encryption, while Worldpay retains the private key used for decryption.

1.12.2.1 Using the Browser JavaScript API for Apple Pay on the Web

In this scenario, the Worldpay eProtect Customer Browser JavaScript API controls the fields on your
checkout page that hold sensitive card data. When the cardholder clicks the Apple Pay button,
communication is exchanged with Apple Pay via the JavaScript API to obtain the PKPaymentToken.
From this point forward, your handling of the transaction is identical to any other eProtect transaction. The
eProtect server returns a Registration ID (low-value token) and your server constructs the cnpAPI
transaction using that ID. See the Worldpay eComm eProtect Integration Guide for JavaScript and HTML
page examples and more information on using the browser JavaScript API.
Step 1, Step 2, and Step 3 are the same as those outlined in Overview of Apple Pay Operation on page
51. The process after Step 3 is detailed below (and shown in Figure 1-7):
4. Your website sends the PKPaymentToken to our secure server via the JavaScript Browser API and
eProtect returns a Registration ID.
5. Your website forwards the transaction data along with the Registration ID to your order processing
server, as it would with any eProtect transaction.
6. Your server constructs/submits a standard cnpAPI Authorization/Sale transaction using the
Registration ID, setting the <orderSource> element to applepay.
7. Using the private key, Worldpay decrypts the PKPaymentToken associated with the Registration ID
and submits the transaction with the appropriate information to the card networks for approval.
8. Worldpay sends the Approval/Decline message back to your system. This message is the standard
format for an Authorization or Sale response and includes the Worldpay token.
9. You return the Approval/Decline message to your website.
Table 1-14 lists the requirements for your customers’ Apple devices when making purchases via Apple
Pay on the Web.

NOTE: Table 1-14 represents data available at the time of publication of this document, and is
subject to change. See the latest Apple documentation for current information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

52
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

TABLE 1-14 Apple Pay on the Web Compatible Devices

Apple Device Operating System Browser

iPhone 6 and later iOS 10 and later

iPhone SE

iPad Pro iOS 10 and later

iPad Air 2 and later
iPad Mini 3 and later

Apple Watch Watch OS 3 and later

Paired with iPhone 6 and
later
Safari only
iMac macOS Sierra and later
Paired with any of the above
mobile devices with ID Touch
for authentication

MacBook macOS Sierra and later

Paired with any of the above
mobile devices with ID Touch
for authentication

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

53
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

FIGURE 1-7 Data/Transaction Flow using Browser JavaScript API for Apple Pay on the Web

1.12.2.2 Using the Worldpay Mobile API for Apple Pay

In this scenario, your native iOS application performs an HTTPS POST of the Apple Pay
PKPaymentToken using the Worldpay Mobile API for Apple Pay. From this point forward, your handling of
the transaction is identical to any other PayPage transaction. The PayPage server returns a PayPage
Registration ID and your Mobile App (or server) constructs the cnpAPI transaction using that ID.
Step 1, Step 2, and Step 3 are the same as those outlined in Overview of Apple Pay Operation on page
51. The process after Step 3 is detailed below and in Figure 1-8.
4. Your native iOS application sends the PKPaymentToken to our secure server via an HTTPS POST
and eProtect returns a Registration ID. Please refer to the Worldpay eComm eProtect Integration
Guide for additional information.
5. Your native iOS application forwards the transaction data along with the Registration ID to your order
processing server, as it would with any eProtect transaction.
6. Your server constructs/submits a standard cnpAPI Authorization/Sale transaction using the
Registration ID, setting the <orderSource> element to applepay.
7. Using the private key, Worldpay decrypts the PKPaymentToken associated with the Registration ID
and submits the transaction with the appropriate information to the card networks for approval.
8. Worldpay sends the Approval/Decline message back to your system. This message is the standard
format for an Authorization or Sale response and includes the Worldpay token.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

54
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

9. You return the Approval/Decline message to your mobile application.

FIGURE 1-8 Data/Transaction Flow using the Worldpay Mobile API for Apple Pay

1.12.2.3 Submitting the Apple Pay PKPaymentToken in a cnpAPI Message

In this scenario, you submit the Apple Pay PKPaymentToken to the Worldpay eCommerce platform using
a new cnpAPI structure (see applepay), typically from your server. As with the previous scenario,
Worldpay decrypts the PKPaymentToken from Apple Pay using the private key.
Step 1, Step 2, and Step 3 are the same as those outlined in Overview of Apple Pay Operation on page
51. The process after Step 3 is detailed below and in Figure 1-9.
4. Your mobile application forwards the PKPaymentToken from Apple Pay, along with other normal
information from the transaction (such as Bill To and Ship To Address), to your order processing
server.
5. You do not decrypt the PKPaymentToken, but rather forward the data to Worldpay in the
Authorization/Sale transaction using the cnpAPI <applepay> element structure instead of <card>
(Server-side API submit) and setting the <orderSource> element to applepay.
6. Using the private key retained by Worldpay, we decrypt the PKPaymentToken and submit the
transaction with the appropriate information to the card networks for approval.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

55
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

7. Worldpay sends the Approval/Decline message back to your system. This message is the standard
format for an Authorization or Sale response.
8. You return the Approval/Decline message to you mobile application.

FIGURE 1-9 Data/Transaction Flow with Direct Submission of PKPaymentToken via cnpAPI

1.12.3 Merchant Decryption of Apple Pay PKPaymentToken

Using this process, the responsibility for the decryption of the PKPaymentToken from Apple Pay falls to
you. After completing the first three steps of the process as detailed in the Overview of Apple Pay
Operation section and depicted by the green and blue arrows in Figure 1-10, the process continues as
follows:
4. Your mobile application forwards the PKPaymentToken from Apple Pay, along with other normal
information from the transaction (such as Bill To and Ship To Address), to your order processing
server.
5. Using your private key, you decrypt the PKPaymentToken, construct the Authorization/Sale
transaction, and submit it to Worldpay. In this case, you would populate the cnpAPI <number>
element with the device primary account number, the <expDate> element with the expiration date,
and the <authenticationValue> field with the cryptogram extracted from the PKPaymentToken.
Also, set the <orderSource> element to applepay (Server-side API submit).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

56
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

6. Worldpay detects that this is an Apple Pay transaction and submits the transaction with the
appropriate information to the card networks for approval.
7. Worldpay sends the Approval/Decline message back to your system. This message is the standard
format for an Authorization or Sale response.
8. You return the Approval/Decline message to your mobile application.

FIGURE 1-10 Data/Transaction Flow with Merchant Decryption of Apple Pay PKPaymentToken

1.12.4 Recurring Payments with Apple Pay

When you submit the first transaction in a recurring/installment stream, or when storing credentials for
future purchases, you must set the <processingType> element to either initialRecurring,
initialInstallment, or initialCOF (Card on File), as applicable. With the exception of an American Express
transaction, the XML response message includes the <networkTransactionId> element. You must
retain the value returned for use in future transactions. When you submit the next and all subsequent
transactions in the recurring/installment stream, set the <orderSource> to recurring or installment as
appropriate, and include the networkTransactionId value in the
<originalNetworkTransactionId> element. For a CoF transaction, set the <orderSource> to
ecommerce and the <processingType> element to either merchantInitiatedCOF, or
cardholderInitiatedCOF (Card on File), as applicable.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

57
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.13 eCommerce Solution for Google Pay™

Google® makes hundreds of products used by billions of people across the globe, from YouTube and
Chrome to Google Pay and, of course, Google Search. Hundreds of millions of them add payment cards
to their Google Accounts, which they can use to check out from any Google product - without needing to
re-enter their payment info.
With the new Google Pay API, you can enable the same effortless checkout experience for your own
products and services. The new API is an on-line payment method that lets your customers use the cards
they've saved to their Google Account to pay quickly and easily in your apps. and on your websites. By
clicking the Google Pay button, customers can choose a payment method saved in their Google Account
and finish checkout in a few, simple steps.
You can use the Google Pay API to simplify payments for customers who make purchases in Android
applications or on Chrome with a mobile device.
Worldpay supports two methods for merchants to submit Google Pay transactions from Mobile
applications to the eCommerce platform. The preferred method involves you sending certain
Worldpay-specific parameters to Google. The response from Google includes a Worldpay
paypageRegistrationId, which you use normally in your payment transaction submission to Worldpay.
With the alternate method, you receive encrypted information from Google, decrypt it on your servers, and
submit the information to Worldpay in a payment transaction.
This document provides an overview of both methods and includes the following sections:
• Branding Requirements
• Google Pay using eProtect
• Merchant Decryption Method
• Recurring Payments with Google Pay

1.13.1 Branding Requirements

You are required to implement the Google Pay branding requirement on pages where the consumer is
presented with payment options. Go to https://developers.google.com/payments/brand-guidelines for
more information, including guidelines on the Google brand mark, button label, and button container.

1.13.2 Google Pay using eProtect

This is the recommended and typical method of implementing Google Pay for Mobile Applications on the
Worldpay eCommerce platform. The steps that follow, along with Figure 1-11, illustrate the high level flow
of messages associated with an Google Pay purchase, when utilizing the Worldpay eProtect service.

NOTE: This process assumes you have integrated with Google using the method that returns the
Worldpay low-value token (paypageRegistrationId) from Google following the Full Wallet
request.

1. When the consumer clicks the Google Pay button in your application, the action triggers a
PaymentDataRequest to Google. In the PaymentDataRequest, you must set a new object

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

58
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

PaymentMethodTokenizationParameters indicating that you are using Worldpay. Use the

following code sample as a guide to setting this field.

Setting the PaymentMethodTokenizationParameters

PaymentMethodTokenizationParameters parameters =
PaymentMethodTokenizationParameters .newBuilder()
.setPaymentMethodTokenizationType(PaymentMethodTokenizationType.PAYMENT_GATEWAY)
.addParameter("gateway","vantiv")
.addParameter("vantiv:merchantPayPageId",payPageId)
.addParameter("vantiv:merchantOrderId",orderId)
.addParameter("vantiv:merchantTransactionId",id)
.addParameter("vantiv:merchantReportGroup",reportGroup)
.build();

IMPORTANT: Use the same orderId value on all calls (i.e., Google, Register Token,
Authorization, Sale, etc.). By using the same orderId, customers can track their orders when using
a Google-provided app.

Setting New Object in the PaymentDataRequest

PaymentDataRequest request = PaymentDataRequest.newBuilder()
.addAllowedPaymentMethods (new List,int.(){
WalletConstants.PAYMENT_METHOD_CARD,
WalletConstants.PAYMENT_METHOD_TOKENIZED_CARD)
.setMerchantName(Constants.MERCHANT_NAME)
.setPhoneNumberRequired(true)
.setShippingAddressRequired(true)
.setCurrencyCode(Constants.CURRENCY_CODE_USD)
.setEstimatedTotalPrice(cartTotal)
.setCart(Cart.newBuilder()
.setCurrencyCode(Constants.CURRENCY_CODE_USD)
.setTotalPrice(cartTotal)
.setLineItems(lineItems)
.build())
.setPaymentMethodTokenizationParameters(parameters)
.build();
The information returned by Google in the PaymentDataRequest object may include a masked card
number (last-four digits exposed) and shipping information. The consumer has the option of changing
this information. If any info changes, Google Pay returns an updated PaymentDataRequest object.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

59
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

2. Upon confirmation of the order by the consumer your application initiates a FullWalletRequest to
Google.
3. After receiving the FullWalletRequest from your application, Google submits the card information
to Worldpay eProtect. The eProtect servers return a low-value token (paypageRegistrationId).
4. Google returns the low-value token to your application along with the Full Wallet information.
5. Your applications sends the transaction information to your servers along with the low-value token.
Your servers submit the Auth/Sale transaction to the Worldpay eComm platform. You must set the
orderSource to androidpay in the transaction.

NOTE: Instead of submitting a Auth/Sale transaction, you can submit a Register Token transaction
to convert the low-value token to a Worldpay high-value token. You would then use the high-value
token in subsequent transactions submitted to the eComm platform.

6. Worldpay processes your transaction normally and returns the results along with a high-value token.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

60
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

FIGURE 1-11 High Level Message Flow for Google Pay using eProtect

Web App/ Merchant Card

Mobile App Server eProtect eComm Networks

3
4

1.13.3 Merchant Decryption Method

Using this process, the responsibility for the decryption of the encrypted payload from Google Pay falls to
you. The steps that follow, along with Figure 1-12, illustrate the high level flow of messages associated
with an Google Pay purchase, when you perform the decryption of the encrypted payload.

NOTE: The process assumes you have integrated with Google using the method that returns the
encrypted payload from Google following the Full Wallet request.

1. When the consumer clicks the Google Pay button in your application, the action triggers a
PaymentDataRequest to Google. The information returned by Google in the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

61
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

PaymentDataRequest object may include a masked card number (last-four digits exposed) and
shipping information. The consumer has the option of changing this information. If any info changes,
Google Pay returns an updated PaymentDataRequest object.
2. Upon confirmation of the order by the consumer your application initiates a FullWalletRequest to
Google. Google also returns the encrypted payload. The encrypted payload is a UTF-8 encoded
serialized JSON dictionary with the following keys:
• encryptedMessage (string base64) - an encrypted message containing the payment credentials
• ephemeralPublicKey (string base64) - the ephemeral public key associated with the private key
to encrypt the message
• tag (string base64) - MAC of encryptedMessage
3. Your application sends the encrypted payload along with the transaction information to your server.
4. Your server decrypts the encrypted payload extracting the payment, which is a UTF-8 encoded,
serialized JSON dictionary with the following keys:
• dpan (string (digits only)) - the device-specific personal account number (i.e., device token)
• expirationMonth (number) - the expiration month of the DPAN (1 = January, 2 = February, etc.)
• expirationYear (number) - The four-digit expiration year of the DPAN (e.g., 2015)
• authMethod (string) - the constant 3DS (may change in future releases).
• 3dsCryptogram (string) - the 3DSecure cryptogram
• 3dsEciIndicator ((optional) string) - ECI indicator per 3DSecure specification

Example of Decrypted Credentials in JSON

{
“dpan”: “4444444444444444”,
“expirationMonth”: 10,
“expirationYear”: 2018,
“authMethod”: “3DS”,
“3dsCryptogram”: “AAAAAA...”,
“3dsEciIndicator”: “eci indicator”
}
After decryption, submit the Authorization/Sale transaction to Worldpay, setting the orderSource
element to androidpay and populating the following cnpAPI elements with the decrypted information:
• number - dpan value
• expDate - MMYY derived from the expirationMonth and expirationYear values
• authenticationValue - the 3dsCryptogram value
5. Worldpay processes your transaction normally and returns the results in the response message.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

62
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

FIGURE 1-12 High Level Message Flow for Google Pay using Merchant Decryption

Web App/ Merchant Card

Mobile App Server eComm Networks

1.13.4 Recurring Payments with Google Pay

When you submit the first transaction in a recurring/installment stream, or when storing credentials for
future purchases, you must set the <processingType> element to either initialRecurring,
initialInstallment, or initialCOF (Card on File), as applicable. With the exception of an American Express
transaction, the XML response message includes the <networkTransactionId> element. You must

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

63
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

retain the value returned for use in future transactions. When you submit the next and all subsequent
transactions in the recurring/installment stream, set the <orderSource> to recurring or installment as
appropriate, and include the networkTransactionId value in the
<originalNetworkTransactionId> element. For a CoF transaction, set the <orderSource> to
ecommerce and the <processingType> element to either merchantInitiatedCOF, or
cardholderInitiatedCOF (Card on File), as applicable.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

64
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.14 Amazon Pay

Amazon Pay provides consumers a secure, trusted, and convenient method of using their Amazon
account/credentials to make purchases on merchant sites. To do this, Amazon embeds a widget into your
checkout flow that allows the consumer to sign into their Amazon account and select one of their payment
methods, without leaving your site. You receive an token from Amazon Pay, which you submit to
Worldpay in an authorization or Sale transaction. Figure 1-13 provides an overview of the Amazon
Pay/Worldpay message flow.

FIGURE 1-13 Amazon Pay Message Flow

1. After the consumer signs in and consents to the charge using Amazon Pay, your system
communicates with Amazon Pay receiving a permission ID. The consumer then selects one of the
payment methods saved in the Amazon Pay profile. Your systems again communicates with Amazon
Pay receiving an Amazon Pay token and payment information in return.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

65
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

2. Your system submits an Authorization or Sale transaction to Worldpay (see Authorization example
below), using the Amazon Pay token (cnpToken element).
3. Worldpay communicates with Amazon Pay to retrieve the PAN information associated with the
Amazon Pay token. We then send the transactional information to the card brands for approval.
4. Worldpay sends the sends the Approval/Decline back to your system.

Example: Authorization Message with Amazon Pay Token

<authorization id="99999" customerId="444" reportGroup="RG1">
<orderId>F12345</orderId>
<amount>15000</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</billToAddress>
<shipToAddress>
<name>Jane Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</shipToAddress>
<token>
<cnpToken>111100010103AMZN</cnpToken>
</token>
</authorization>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

66
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.15 Healthcare Card Feature

Today, there are several types of Healthcare accounts that allow participants to use pre-tax money for the
purchase of IRS approved healthcare products and services, such as prescription medications and office
visit payments/co-pays. The most common of these accounts are Flexible Spending Accounts (FSAs),
Health Reimbursement Arrangements (HRAs), and Health Savings Accounts (HSAs). In order to provide
consumers with a more convenient method of making use of these accounts, certain issuers provide
signature based, Mastercard or Visa branded, healthcare payment debit cards.
To facilitate the processing of transactions related to these cards, Worldpay augmented the cnpAPI with
elements specific to Healthcare card purchases. We added the healthcareIIAS element to the
Authorization and (Conditional) Sale transaction types. You use this element and its children to detail the
costs associated with Healthcare related, IIAS approved items purchased by the consumer. The example
below shows an Authorization transaction with IIAS items.

Example: Authorization with healthcareIIAS Element

NOTE: The example below includes the dentalAmount element to show all available amount
classifications. Since this is an optional element and has a value of 0 in the example, you can omit it.
Also, note that the visionAmount is not included in the totalHealthcareAmount, since this is a
Visa transaction.

<cnpOnlineRequest version="12.3" xmlns="http://www.vantivcnp.com/schema"

merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<authorization id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>123456789</orderId>
<amount>5500</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Smith</name>
<addressLine1>100 Main St</addressLine1>
<city>Boston</city>
<state>MA</state>
<zip>12345</zip>
<email>[email protected]</email>
<phone>555-123-4567</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4000000000000001</number>
<expDate>1211</expDate>
<cardValidationNum>555</cardValidationNum>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

67
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

</card>
<cardholderAuthentication>
<authenticationValue>BwABBJQ1gJDUCAAAAAAA=</authenticationValue>
<authenticationTransactionId>gMV75TmjAgk=</authenticationTransactionId>
</cardholderAuthentication>
<allowPartialAuth>true</allowPartialAuth>
<healthcareIIAS>
<healthcareAmounts>
<totalHealthcareAmount>5500</totalHealthcareAmount>
<RxAmount>4000</RxAmount>
<visionAmount>5000</visionAmount>
<clinicOtherAmount>1500</clinicOtherAmount>
<dentalAmount>0</dentalAmount>
</healthcareAmounts>
<IIASFlag>Y</IIASFlag>
</healthcareIIAS>
</authorization>
</cnpOnlineRequest>

Please keep in mind the additional following requirements/recommendations:

NOTE: The information below is not intended as an exhaustive list of the requirements for the
acceptance of Healthcare cards by merchants. While Worldpay may be able to provide some
information, merchants are responsible for the awareness of and adherence to all applicable
regulatory requirements imposed by the Internal Revenue Service, other government agencies, and
other interested parties (for example, Visa, Mastercard, SIGIS, etc.)

• You must become a member of the Special Interest Group for IIAS Standards (SIGIS)
• You must obtain and maintain SIGIS certification
• Merchants, except those with healthcare related MCCs, must have an Inventory Information Approval
System (IIAS) used to identify eligible healthcare purchases as defined and required by the Internal
Revenue Code.
• You must obtain special account numbers from Visa and Mastercard to process these transactions
• You must support data retention and retrieval of line item details for eligible healthcare products
included in Healthcare Card transactions
• You must complete Worldpay Certification Testing for the use of this feature, as well as the Partial
Auth feature.
• For Visa transaction, do not include the visionAmount in the totalHealthcareAmount.
• Transactions must include the IIASFlag element set to Y.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

68
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16 Supported Transaction Types

cnpAPI Batch processing supports all transaction types except Voids, eCheck Voids and Private Label
Gift Card reversal transactions, which are handled as Online transactions only. Online processing handles
all transaction types. This section provides a description of each transaction type, information concerning
its use, and any special considerations.

NOTE: For information about Dynamic Payout Funding Instructions please refer to Appendix D,
"PayFac Dynamic Payout".

1.16.1 Authorization Transaction

The Authorization transaction enables you to confirm that a customer has submitted a valid payment
method with their order and has sufficient funds to purchase the goods or services they ordered. Setting
the <allowPartialAuth> element to true in the Authorization request enables the system to return
authorizations for a portion of the order amount for cases where the card does not have an adequate
credit limit or balance available for the full amount.
An approved Authorization reduces the customer's credit limit (or bank balance, in the case of a debit
card) by the amount of the approval by placing the amount on hold. If you have the Prepaid Indicator
feature enabled, the Authorization response also includes an element that indicates if the card is Prepaid,
as well as an element indicating the available balance on the card.

NOTE: To obtain better interchange rates, you should always perform an AVS check either as a
standalone transaction, or as part of the Authorization/Sale transaction.
If you settle in a currency other than US or Canada, you cannot use partial Authorizations.
While most merchants perform Authorizations as Online transactions, there is no requirement to do
so.

The lifespan of an Authorization depends upon the payment method. Table 1-15 provides information
concerning Authorization lifespans for various card types and alternate payment methods.

TABLE 1-15 Lifespan of Payment Authorizations

Payment Type Lifespan of Authorization

Mastercard 7 days

Visa 7 days

American Express 7 days

Discover 10 days

PayPal 29 days total by default; Worldpay recommends capture

submission within three days. For more information, see the
Worldpay eComm PayPal Integration Guide.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

69
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

As long as the authorization has not expired, or the amount exhausted, you can use it repeatedly to fulfill
an order. This would be the case if the Authorization covered multiple items with staggered deliveries. In
this scenario, you would issue a Partial Capture transaction as each item shipped until the order was
completely fulfilled.

NOTE: If you obtain an Authorization through approved vendors for voice and terminal
authorizations, you would use a Capture Given Auth transaction to deposit the funds (see Capture
Given Auth Transaction on page 73).

1.16.1.1 AVS Only Transaction

An AVS Only transaction is a variation of an Authorization transaction that uses the Address Verification
System to enable you to verify that a customer supplied address matches the billing address associated
with the card. To submit an AVS Only transaction, submit an Authorization transaction with the <amount>
element set to 000 and the optional billToAddress element with appropriate child values.

NOTE: To obtain better interchange rates, you should always perform an AVS check either as a
standalone transaction, or as part of the Authorization/Sale transaction.

1.16.2 Authorization Reversal Transactions

The primary use of Authorization Reversal transactions is to eliminate any unused amount on an
unexpired Authorization. Issuing an Authorization Reversal has the benefit of freeing any remaining held
amount that reduces the buying power of your customer. Potentially, this both increases customer
satisfaction and can allow them to proceed with additional purchases that may otherwise be blocked by
credit limits. It also helps you avoid any misuse of Auth fees imposed by the card associations.

NOTE: For American Express transactions, the reversal amount must match the authorization
amount. American Express does not allow partial reversals and reversals against remaining
amounts after a partial capture. Attempts to perform these types of reversals result in a Response
Code of 336 - Reversal amount does not match Authorization amount.

For example, consider the following scenario. A customer with a $6,000 credit limit orders a $3,000 stereo
system, but the stereo is a discontinued item. The merchant notifies the customer, but does not perform
and Authorization Reversal. The customer attempts to submit a new order for a $3,001 stereo.
• If the customer uses the same credit card for both orders, the second order could be denied, since
the account’s remaining credit limit is only $3,000.
• If the customer had used the same debit card for both orders, the second order places the customer’s
bank account in an overdraft situation (assuming a starting balance of $6,000).
Either of these situations can result in the merchant losing a sale, as well as receiving a call from an
angry customer.
Another advantage of Authorization Reversal transactions occurs on Visa and Mastercard transactions. In
order for you to qualify for the best possible interchange rates from Visa/Mastercard, the amount of the
Capture must match the amount of the associated Authorization. In order to take advantage of this
situation for you, if the Capture amount is less than the associated Authorization amount, Worldpay

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

70
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

automatically performs a partial Authorization Reversal for the unused amount (also see Capture Request
on page 220).

1.16.2.1 Notes on the Use of Authorization Reversal Transactions

This section provides additional information concerning the requirements of and exceptions to the use of
Authorization Reversal transactions.
• Worldpay supports Authorization Reversal transactions for the following methods of payment: PayPal,
Mastercard, Visa, Discover, Diners Club, and JC and American Express, but American Express and
PayPal only support reversals of the entire Authorized amount (no partial reversals).
• All transactional data, including associated Authorizations, Captures, and Refunds, must use cnpAPI
format.
• Worldpay recommends that you send the Authorization Reversal transaction using the same
submission method (Batch or Online) as used for the Capture transaction. This is to eliminate a
possible race condition that may occur if you submit an Online Authorization Reversal prior to the
processing of a Batch containing the associate Capture transaction.
• For Batch transactions, send Authorization Reversal transactions in a session separate from the both
the associated Authorization and the associated Capture transactions.
• For Online transactions, when following an Authorization with an Auth Reversal, allow a minimum of
one minute between the transactions.
• For Visa and Mastercard transactions, Worldpay automatically performs a partial Authorization
Reversal, if the Capture amount is less than the associated Authorization amount.
• If you do not specify an amount (<amount> element) in the Authorization Reversal, Worldpay
reverses the total amount of the associated Authorization.
• Do not send an Authorization Reversal against an expired Authorization. This results in a 306 - Auth
expired, so amount does not need to be reversed error. When an Authorization expires, the hold
amount is automatically reversed.
• Do not send an Authorization Reversal against an Authorization that does not exist in our system. For
example, if you sends a reversal against an Authorization that failed or an Authorization that was
declined, the Authorization Reversal returns a 360 - No transaction found with specified transaction Id
error.
• Do not send an Authorization Reversal against a payment type that does not support Authorization
Reversals. This results in a 335 - This method of payment does not support reversals error.
• Do not send an Authorization Reversal for a fully depleted Authorization. This results in a 111 -
Authorization amount has already been depleted error.
• Do not use an Authorization Reversal to reverse an Authorization on a (Closed Loop) Gift Card. Use a
Gift Card Auth Reversal instead (see Gift Card Auth Reversal Transactions on page 276).

1.16.2.2 Using Authorization Reversal to Halt Recycling Engine

If you are using the Recycling Engine to optimize your authorizations and need to discontinue the
automatic recycling of the transaction, you use an Authorization Reversal transaction to halt the retries.
For example, if a customer cancels an order and the authorization for the order is being retried by the
Recycling Engine, you submit an Authorization Reversal transaction to halt the automatic recycling of the
authorization.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

71
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

NOTE: If the initial transaction you submitted is a Sale (conditional deposit) rather than an
Authorization, you use a Void transaction to halt the recycling.

1.16.3 Activate Transaction

You use an Activate transaction to change the status of a (Closed Loop) Gift Card from an inactive to an
active state with a value as specified by the amount element. You can also use this transaction type to
create a Virtual Gift Card.

1.16.4 Activate Reversal Transaction (Online Only)

You use as Activate Reversal transaction to change the status of a newly activated (Closed Loop) Gift
Card from active to inactive, thus reversing the operation of an Active transaction. The Activate Reversal
references the associated Activate transaction by means of the cnpTxnId element returned in the
Activate response.

1.16.5 Balance Inquiry Transaction

You use the Balance Inquiry transaction to determine the balance available for use on a (Closed Loop)
Gift Card.

1.16.6 Cancel Subscription Transaction

If you are using the Recurring Engine, you create Subscriptions as part of an Authorization or Sale
transaction. You use the Cancel Subscription transaction to cancel the specified subscription, removing
the transaction stream managed by the Recurring Engine.

1.16.7 Capture Transaction

You use a Capture transaction to transfer previously authorized funds from the customer to you after
order fulfillment. You can submit a Capture transaction for the full amount of the Authorization, or for a
lesser amount by setting the partial attribute to true.

NOTE: If you settle in a currency other than US or Canada, you cannot use partial captures.
For a Visa or Mastercard transaction, if you submit a Capture for an amount less than the
Authorized amount, Worldpay automatically issues a partial Authorization Reversal for the balance
of the Authorized amount.

Do not use a Capture transaction to capture funds on a (Closed Loop) Gift Card transaction; use a Gift
Card Capture instead (see Gift Card Capture Transactions on page 278).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

72
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16.8 Capture Given Auth Transaction

Similar to a Capture transaction, you use a Capture Given Auth transaction to transfer previously
authorized funds from the customer to you after fulfillment. However, you typically use a Capture Given
Auth transaction if the associated Authorization occurred outside of the system (for example, if you
received a telephone Authorization). Another possible use for a Capture Given Auth transaction is if the
Authorization transaction occurred within the system, but the cnpTxnId is unknown by the submitting
party (for example, if the Auth was submitted by a merchant, but a fulfiller submits a Capture Given Auth).
Whenever you submit a Capture Given Auth transaction, Worldpay attempts to match it to an existing
Authorization using COMAAR data (Card Number, Order Id, Merchant Id, Amount, Approval Code, and
(Auth) Response Date) in order to obtain a better Interchange rate for the transaction. The application
uses the following matching logic:
• If the Order Id was either not submitted (blank, spaces, or null) or does not match any Auth in the
system, it is ignored and the matching attempt proceeds using the remaining COMAAR data.
• If the matching operation results in multiple possible matches, the application selects the
Authorization with the lowest amount that is greater than or equal to the Capture Given Auth amount.

NOTE: In all cases, the Authorization amount must always be greater than or equal to the Capture
Given Auth amount.

• If necessary, the application further narrows the match candidates to the one with the most recent
response date.

NOTE: If Worldpay can match the Capture Given Auth to an Authorization and the following
conditions are met: the card type is Visa and the Capture Given Auth amount is less than the
Authorization amount, then Worldpay issues an Auth Reversal transaction for the balance of the
Authorization.
We do this to obtain the best possible interchange rates from Visa.

1.16.9 Create Plan Transaction

You use the Create Plan transaction to define several attributes of a recurring payment schedule. Later,
as part of an Authorization or sale transaction, you can associate existing, active plans with Subscriptions.
This association establishes a recurring payment schedule managed by the Worldpay eComm Recurring
Engine.

1.16.10 Credit Transaction

You use a Credit transaction to refund money to a customer, even if the original transaction occurred
outside of the system. You can submit refunds against any of the following payment transactions:

NOTE: If enabled for Auth for Refund, we automatically generate an Authorization before
processing the Credit. If the Issuing Bank declines the Authorization, you receive the decline
response code for the Authorization in the response message. If the Authorization passes, you
receive an Approved response code in the response message, but still must check the Declined
Transaction report to verify the Issuing Bank did not decline the Credit transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

73
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

• Capture Transaction
• Capture Given Auth Transaction
• Force Capture Transaction
• Sale Transaction
• External Sale or Capture

NOTE: Worldpay recommends you send all Credit transactions in a Batch separate from the
associated Capture or Sale transactions.

1.16.11 Deactivate Transaction

You use a Deactivate transaction to change the status of a (Closed Loop) Gift Card from an active to an
inactive state.

1.16.12 Deactivate Reversal Transaction (Online Only)

You use a Deactivate Reversal transaction to change the status of a newly deactivated Gift Card from
inactive to active, thus reversing the operation of an Deactivate transaction. The Deactivate Reversal
references the associated Deactivate transaction by means of the cnpTxnId element returned in the
Deactivate response.

1.16.13 Deposit Reversal Transaction (Online Only)

Used only for (Closed Loop) Gift Card related transactions, a Deposit Reversal transaction to reverse the
funds capture initiate by either a Capture or Sale transaction. The Deposit Reversal references the
associated Capture/Sale transaction by means of the cnpTxnId element returned in the Capture/Sale
response. You should never attempt to use this transaction type to reverse credit card or Direct Debit
transactions.

1.16.14 eCheck Credit Transaction

Similar to a Credit transaction, you use an eCheck Credit transaction to refund money to a customer, but
only when the method of payment was an eCheck Direct Debit. You can submit an eCheck Credit
transaction regardless of whether the original transaction occurred in or out of the system.

1.16.15 eCheck Prenotification Credit Transaction

You use this non-monetary transaction to verify the consumer’s account information prior to submitting an
eCheck Credit transaction (also see eCheck Prenotification on page 49). This transaction type is only
supported for US transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

74
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16.16 eCheck Prenotification Sale Transaction

You use this non-monetary transaction to verify the consumer’s account information prior to submitting an
eCheck Sale transaction (also see eCheck Prenotification on page 49). This transaction type is only
supported for US transactions.

1.16.17 eCheck Redeposit Transaction

You use this transaction type to manually attempt redeposits of eChecks returned for either Insufficient
Funds or Uncollected Funds. You can use this element in either Online or Batch transactions.

NOTE: Do not use this transaction type if you are enabled for the Auto Redeposit feature. If you are
enabled for the Auto Redeposit feature, the system will reject any echeckRedeposit transaction
you submit.

1.16.18 eCheck Sales Transaction

You use an eCheck Sales transaction to transfer funds from the customer to you after order fulfillment. It
is the eCheck equivalent of a Capture transaction. Funding usually occurs within two days. You can also
submit this transaction type as a conditional capture, which makes the processing of the deposit
conditional upon a successful verification. If the verification fails, the deposit is not processed.

1.16.19 eCheck Verification Transaction

You use an eCheck Verification transaction to initiate a comparison to a database containing information
about checking accounts. The database may include information as to whether the account has been
closed, as well as whether there is a history of undesirable behavior associated with the account/account
holder. This transaction type is only supported for US transactions.

1.16.20 eCheck Void Transaction (Online Only)

You use an eCheck Void transaction to either halt automatic redeposit attempts of eChecks returned for
either Insufficient Funds or Uncollected Funds, or cancel an eCheck Sale transaction, as long as the
transaction has not yet settled. This also applies to merchant initiated redeposits. You can use this
element only in Online transactions.

1.16.21 Force Capture Transaction

A Force Capture transaction is a Capture transaction used when you do not have a valid Authorization for
the order, but have fulfilled the order and wish to transfer funds.

NOTE: Merchants must be authorized by Worldpay before processing this transaction. In some
instances, using a Force Capture transaction can lead to chargebacks and fines.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

75
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16.22 Gift Card Auth Reversal

You use the Gift Card Auth Reversal transaction to reverse an Authorization on a (Closed-loop) Gift Card.
This removes the hold on the previously authorized amount, freeing those funds for additional purchases
by the cardholder.

1.16.23 Gift Card Capture

You use the Gift Card Capture transaction to capture or deposit previously authorized funds on a
(Closed-loop) Gift Card.

1.16.24 Gift Card Credit

You use a Gift Card Credit transaction to refund money to a customer that used a (Closed Loop) Gift Card
for the purchase, even if Worldpay did not process the purchase. You have a choice of two structures.
You use the message type containing a transaction Id to apply a credit for a transaction processed by
Worldpay. You use the message type containing a order Id to apply a credit for a transaction not
processed by Worldpay.

1.16.25 Load Transaction

You use a Load transaction to add funds to an active Gift Card. The load amount cannot exceed the
maximum allowed amount for the Gift Card. If you attempt to load more than the maximum amount, the
transaction will be declined with a response Code of 221 - Over Max Balance.

1.16.26 Load Reversal Transaction (Online Only)

You use a Load Reversal transaction to reverse the operation of a Load transaction, removing the newly
loaded amount from the Gift Card. You cannot perform a partial Load Reversal. This transaction always
reverses the full amount of the referenced Load transaction.

1.16.27 Refund Reversal Transaction (Online Only)

The Refund Reversal transaction is a (Closed Loop) Gift Card only transaction that reverses the operation
of a Refund transaction on the Gift Card. You cannot perform a partial Refund Reversal. This transaction
always reverses the full amount of the referenced Refund transaction.

1.16.28 Register Token Transaction

You use the Register Token transaction to submit a credit card number, eCheck account number, or
Registration Id to us and receive a token in return. While you can submit Register Token transactions at
any time, typically, you would make use of this transactions when initially converting to the use of tokens.
In this case you would submit large quantities of credit cards/eCheck account numbers in Batches and
replace them in your database with the tokens returned.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

76
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16.29 Sale Transaction

The Sale transaction enables you to both authorize fund availability and deposit those funds by means of
a single transaction. The Sale transaction is also known as a conditional deposit, because the deposit
takes place only if the authorization succeeds. If the authorization is declined, the deposit will not be
processed.

NOTE: If the authorization succeeds, the deposit will be processed automatically, regardless of the
AVS or CVV2 response.
To obtain better interchange rates, you should always perform an AVS check either as a standalone
transaction, or as part of the Authorization/Sale transaction.

1.16.30 Status Query Transaction

The Status Query Transaction allows you to verify that an Online transaction submitted within the prior 24
hours exists in the system. The response will be one of the following:
• A single transaction matching the search criteria
• Multiple transactions matching the search criteria
• Empty results, if no transactions matched the criteria
• A limited response, if a transaction was found, but processing was not complete
As search criteria, you must submit, at a minimum, the id (id attribute) and transaction type (i.e.,
authorization, deposit, void, etc.) of the original transaction, but to narrow the search, you can also include
the transaction id, order id, and the account number (credit, debit, or gift card) from the original
transaction. The response message contains one of four response codes, 150 through 153 (see Payment
Transaction Response Codes on page 832), and the results for the search.

NOTE: Use of this transaction type requires specific permissions. Please speak to your Worldpay
Implementation Consultant for additional information.

1.16.31 Unload Transaction

You use an Unload transaction to remove funds from an active Gift Card. The unload amount cannot
exceed the available balance on the Gift Card. If you attempt to unload more than the available balance,
the transaction will be declined with a response Code of 209 - Invalid Amount.

1.16.32 Unload Reversal Transaction (Online Only)

The Unload Reversal transaction reverses the operation of a Unload transaction, returning the value
removed from the Gift Card by the Unload transaction. You cannot perform a partial Unload Reversal.
This transaction always reverses the full amount of the referenced Unload transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

77
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

1.16.33 Update Card Validation Number Transaction

When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts and stores
the value on a temporary basis for later use in a tokenized Auth/Sale transaction submitted without the
value. This is done to accommodate merchant systems/workflows where the security code is available at
the time of token registration, but not at the time of the Auth/Sale. If for some reason you need to change
the value of the security code supplied at the time of the token registration, use an
updateCardValidationNumOntoken transaction.

1.16.34 Update Plan Transaction

You use the Update Plan transaction to activate/deactivate Plans associated with recurring payments.
When you deactivate a Plan, by setting the active flag to false, you can no longer reference that Plan
for use with subscriptions. Existing subscriptions already using the deactivated Plan will continue to use
the Plan until the subscription is either modified or completed. You can also reactivate a deactivated Plan
by updating the Plan and setting the active flag to true.

1.16.35 Update Subscription Transaction

You use an Update Subscription transaction to change certain subscription information associated with a
recurring payment. Using this transaction type you can change the plan, card, billing information, and/or
billing date. You can also create, update, or delete a Discount and/or an Add On.

1.16.36 Void Transaction (Online Only)

The Void transaction enables you to cancel any settlement transaction as long as the transaction has not
yet settled (see Multiple Daily Delivery on page 5) and the original transaction occurred within the system
(Voids require a reference to a cnpTxnId). Before submitting a Void, please allow a minimum of 60
seconds to elapse after submitting the transaction you wish to void. This timing ensures our system fully
records the first (to be voided) transaction in our database.

NOTE: Do not use Void transactions to void an Authorization. To remove an Authorization use an
Authorization reversal transaction (see Authorization Reversal Transactions on page 70.)
Do not use a Void on a Gift Card transaction. This results in a Response Code of 322 - Invalid
Transaction. Use the appropriate Reversal transaction for Gift Cards.

1.16.36.1 Using Void to Halt Recycling Engine

If you use Recovery or the Recycling Engine service and use Sale transactions (conditional deposits) to
authorize and capture the funds, you must use a Void transaction to discontinue the automatic recycling
of the transaction should the need arise. For example, if a customer cancels an order and the Sale
transaction is being retried by the Recycling Engine, you submit a Void transaction to halt the automatic
recycling of the transaction.

NOTE: If the initial transaction you submitted is an Authorization rather than an Sale, you use an
Authorization Reversal transaction to halt the recycling.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

78
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

When using a Void transaction to halt recycling, there is a possibility that the recycling attempts already
resulted in an approved and captured transaction. If this condition occurs, depending upon your
configuration, the system takes one of the following actions:
• If you are not configured for the Automatic Refund option (default = disabled), the system declines the
Void transaction. You must issue the Credit transaction to refund the money to the consumer. The
daily Recycling file will include the approved/captured transaction.
• If you are configured for the Automatic Refund option and you submit the Void within 24 hours of the
Capture approval, the system issues a Credit transaction on your behalf. The system returns the
transaction Id for the Credit transaction in the Void response message (creditCnpTnxId element).
The daily Recycling file will include the approved/captured transaction only if the file was generated
prior to the system receiving the Void and issuing the automatic refund.
• If you are configured for the Automatic Refund option and you submit the Void outside of the 24 hour
window after the successful Capture, the Void fails and you must issue the Credit transaction
yourself. The Void response message will include one of the following response codes:
– If, in the Void, you referenced the cnpTxnId of the original, declined transaction, the
response/message is 322 - Invalid Transaction.
– If, in the Void, you referenced the cnpTxnId of the successfully captured transaction, the
response/message is 362 - Transaction not Voided - Already Settled.

1.16.37 Instruction-Based Dynamic Payout Transactions

If you are a Payment Facilitator using the Instruction-Based Dynamic Payout model, there are a number
of Batch only transaction types you use to move funds between various accounts, including funding
Sub-merchants. This section provides information about these transaction types. For additional
information, please refer to the Appendix D, "PayFac Dynamic Payout".
• Funding Instruction Void - You use this transaction type to void a submitted funding instruction. You
must submit the void prior to your daily cutoff time for an instruction not yet processed.
• PayFac Credit Transaction - You use this transaction type to move funds from the PayFac
Settlement Account to your Operating Account.
• PayFac Debit Transaction - You use this transaction type to move funds from your Operating
Account to the PayFac Settlement Account.
• Physical Check Credit - You use this transaction type to move funds from the PayFac Settlement
Account to the account of a third party that issues physical checks on your behalf.
• Physical Check Debit - You use this transaction type to move funds from the physical check issuer’s
Account to the PayFac Settlement Account.
• Reserve Credit Transaction - You use this transaction type to move funds from the PayFac
Settlement Account to the Reserve Account.
• Reserve Debit Transaction - You use this transaction type to move funds from the Reserve Account
to the PayFac Settlement Account.
• Sub-merchant Credit Transaction - You use this transaction type to move funds from the PayFac
Settlement Account to the Sub-merchant Account, funding the Sub-merchant.
• Sub-merchant Debit Transaction - You use this transaction type to move funds from the
Sub-merchant Account to the PayFac Settlement Account.
• Vendor Credit - You use this transaction type to move funds from the PayFac Settlement Account to
the account of a third party involved in the sale transactions, but are not the sub-merchant.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

79
© 2020 FIS and/or its affiliates. All rights reserved.
 Introduction

• Vendor Debit - You use this transaction type to move funds from the Vendor Account to the PayFac
Settlement Account.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

80
© 2020 FIS and/or its affiliates. All rights reserved.
 2
Testing Your cnpAPI Transactions

The information provided in this chapter enables you to test and verify that your submitted transaction
data conforms to the required cnpAPI schema. This chapter contains the following topics:
• Certification and Testing Environments
• Overview of Testing
• Transferring Files
• Performing the Required Certification Tests
• Performing the Optional Tests

IMPORTANT: Per PCI DSS Requirements and Security Assessment Procedure, Section 6.4.3,
"Production data (live PANs) are not used for testing or development."

NOTE: This chapter does not include Certification tests for the PayFac Instruction-Based Dynamic
Payout transaction types. Additional information about these transactions, as well as the
Certification tests are in Appendix D, "PayFac Dynamic Payout".

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

81
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.1 Certification and Testing Environments

Worldpay eComm has two testing and certification platforms optimized for different uses. These
environments are called: Sandbox and Pre-Live. This section discusses these various environments, their
uses, and limitations. The certification and testing environments do not have the full capacity,
performance, or availability of the Worldpay eComm Production platform.

2.1.1 Sandbox Environment

The Sandbox environment is a simulator that provides a basic interface for functional level testing of the
cnpAPI, the Chargeback API, and the Merchant Provisioner API (V13 and above) messages. Typically,
merchants using one of the available cnpAPI SDKs (Software Development Kits) would use the Sandbox
to test basic functionality, but you can also use it to test XML messages for any of the three supported
APIs. This is a stateless simulator, so it has no historical transactional data, and does not provide full
functionality. This environment is not intended for certification or regression testing.

NOTE: At his time, the Sandbox does not support Batch transactions (Online transactions only).

Use of the Sandbox does not require a password. The environment is available on the public Internet (at
www.testvantivcnp.com/sandbox/communicator/online). Supporting documentation, including test case
documentation, is available at vantiv-ecommerce.github.io/sandbox.

2.1.2 Pre-Live Environment

The Pre-Live test environment is the platform used for all merchant Certification testing. This environment
should be used by both newly on-boarding Worldpay eComm merchants (for example, coding a direct
XML integration for the first time), and existing Worldpay eComm merchants seeking to incorporate
additional features or functionalities into their current XML integrations. While the Pre-Live system
provides a working version of the Worldpay production system, it does not have the full capacity or
performance of the production platform and operates using simulators rather than communicating with the
card associations.
The Pre-Live environment provides for the self-provisioning of a basic test account via
www.testvantivcnp.com/prelivemid. Using this account, you can submit most standard transaction types,
including those specified in the Certification test sections provided later in this chapter. You will not be
able to test many of the Worldpay eCommerce Value Added Services (VAS) using this basic account. To
add the capability of performing the test scenarios for the VAS services, please have your account owner
request an update to your account.

2.1.2.1 Pre-Live Environment Limitations and Maintenance Schedules

When using the Pre-Live environment for testing, please keep in mind the following limitations and
maintenance schedules:
• The number of merchants configured per organization will be limited to the number necessary to
perform the required certification testing.
• Data retention is limited to a maximum of 30 days.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

82
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: Depending upon overall system capacity and/or system maintenance requirements, data
purges may occur frequently. Whenever possible, we will provide advanced notification.

• Merchant profile and data deleted after 7 consecutive days with no activity.
• Maintenance window - each Tuesday and Thursday from 4:00-8:00 AM ET.
• Maintenance window (Enterprise eProtect) - every other Thursday from 10:00 PM to 6:00 AM ET.
• Daily limit of 1000 Online transactions.
• Daily limit of 10000 Batch transactions.

NOTE: Due to the planned maintenance windows, you should not use this environment for
continuous regression testing.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

83
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.2 Overview of Testing

The purpose of the testing and certification process is to verify that your order entry and supporting
systems construct and send XML messages that comply with the cnpAPI requirements. The testing
process involves submitting Worldpay supplied data for specific fields in a request, and receiving specific
data back in a response. The response returned by Worldpay allows you to verify that you parse the
cnpAPI response file correctly.
Various tables in this chapter provide the data you use while testing, including card numbers, expiration
dates, transaction amounts, and other values as required by the testing process. You use this data as
input to your systems resulting in structured requests that conform to the required cnpAPI schema.

IMPORTANT: The test data supplied does not necessarily account for all data fields/XML elements
in a particular request. Where test data is not supplied, you should provide appropriate information.
You should never override your own system to enter supplied data. If you are unable to enter the
supplied data without overriding your system, please consult your Implementation Consultant
concerning the test and how to proceed.

Typically, Worldpay assigns an Implementation Consultant to work with you after the completion of
contract negotiations. Before you begin the testing phase, your assigned Implementation Consultant
establishes a test account and supplies you with instruction for accessing the account along with the
username and password. You must supply the IP address from which the data originates so we can grant
access.

NOTE: Until you complete all required testing, you will only have access to the test and certification
environment.

The testing process involves the following steps:

2.2.1 Planning for Certification Testing

Before you begin testing, determine which transaction types you will use according to your business
needs. Virtually everyone will make use of the following basic transaction types: Authorization, Capture,
Sale, Credit, and Void. There are several other transaction types and most transaction types offer many
options/optional fields that you may wish to utilize and therefore test. For example, if you decide to offer
Direct Debits as a alternate payment method, there are several associated certification tested required.
Similarly, if you elect to make use of the Insights feature set, there are additional Authorization tests
required for certification.

NOTE: For information about certification testing for eProtect, Chargeback API, and the PayFac
API, please refer to the following documents:
– Worldpay eComm eProtect Integration Guide
– Worldpay eComm Chargeback API Reference Guide
– Worldpay eComm PayFac API Reference Guide

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

84
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.2.2 Required Certification Testing

Certification testing is a required phase of implementing the cnpAPI format. During the certification
testing, a Worldpay, Inc. Implementation Consultant works with you to verify that your transaction
submissions meet the requirements of the cnpAPI specifications. Each transaction type has specific test
scenarios that use specific data sets simulating real transactions. The Worldpay eComm Certification
environment responds to each submission with an XML response message, allowing you to verify that
you have coded correctly to parse and store the transaction data returned to you. For more detailed
information, see Performing the Required Certification Tests on page 93.

2.2.3 Optional Testing

Worldpay, Inc. provides you with test data, test scenarios, a test environment, and credentials for using
that test environment so you can perform these tests on your own keeping in mind the limitations of the
certification environment (see Certification and Testing Environments on page 82). During unattended
testing, you use these resources to perform all of the tests that apply to your business needs.

2.2.4 System Doctor

The System Doctor is a tool you can use to both verify the operation of the Pre-Live environment and to
verify operation and message structures of individual certification tests. Every 30 minutes the System
Doctor runs each certification test specified in this chapter, except the Recycling and Recurring tests. You
access the System Doctor through the Pre-Live iQ (Operations>System Doctor).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

85
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

FIGURE 2-1 System Doctor

As shown in Figure 2-1, the system displays an overall assessment of the system status in the top panel
and the results from each test set in the Test Execution History section (bottom panel). The center panel
has a list of all individual tests by Order Id (pull-down), which you can filter by clicking on or more of the
Search Tag buttons. Selecting one of the Order Ids from the list displays the XML request and response
for that test (see Figure 2-2). You can also display the XML request and response information by
selecting a test run from the Test Execution History and then selecting an individual test from the
expanded list.

NOTE: The search tags filter the Order Ids shown in the selection pull-down, but do so in an ORed
manner. For example, if you select the Visa Filter and the Prepaid Filter, the pull-down displays
Order Ids for tests that either use a Visa card OR a Prepaid card, rather than tests for a Prepaid
Visa card.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

86
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

FIGURE 2-2 XML Request and Response Messages

If one of your certification tests did not yield the expected results, you can use the System Doctor to
determine if the test is performing as expected in the environment and if there is a discrepancy between
your submitted XML and the XML message used in the automated test. If the test failed in the last
automated run, you will know that there is a system issue and can contact your Implementation
Consultant to determine when it will be resolved. If the test passed in the automated run, you can
compare the automated XML message to your submission to determine why you are not receiving the
expected results.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

87
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.3 Transferring Files

As discussed in Communications Protocols on page 2, there are several protocols you can use to submit
your transactions to Worldpay for processing. This section provides additional information concerning the
recommended methods for transferring your cnpAPI Batch and Online transaction files.

2.3.1 Transferring Session Files

This section describes how to FTP your files (not test system specific) and includes the following topics:
• Submitting a Session File for Processing
• Retrieving Processed Session Files

NOTE: Before you begin transferring files via FTP, Worldpay provides the FTP Host and a
username/password for the Worldpay test system.

2.3.1.1 Submitting a Session File for Processing

CAUTION: When submitting a file via FTP/sFTP, verify that the file permission is set to 664.
Also, file naming conventions are crucial to the file submission process. Incorrect file names will
prevent the file from being processed or may stop processing due to an incomplete file transfer.
Do not append .asc to the end of the filename (Step 3). You must replace the .prg extension with
.asc. If .prg appears in the filename, the system will not process the file.
Also, limit the length of the filename to a maximum of 128 characters, including the extension.

1. On your local system, add the extension .prg (lowercase) to the name of the file you want to submit.
For example, you could name the file MerchantName_YYMMDD.prg. Keep in mind the following
rules:
• Spaces are not allowed in the file name
• The .prg extension must be lower case
2. Open your FTP connection to the Worldpay inbound directory and move your file to the Worldpay
directory.
3. After the FTP process completes, change the extension of the transmitted file (in the Worldpay
inbound directory) from .prg to .asc (lowercase). Also, change the file permission to 664. the The
system polls the directory for files with an .asc extension every thirty seconds. When the system
encounters files with the proper extension, it retrieves them for processing.

2.3.1.2 Retrieving Processed Session Files

Depending on the size of your file, your response should be ready within a few minutes. Batches
containing large number of transactions take longer. For example, a batch of 10,000 transactions may
require as long as ten minutes to process.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

88
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: For Account Updater Batch files, the initial response is an acknowledgment file. The system
posts the Batch containing the Account Updater responses after five days.
NOTE:

To retrieve response files from the outbound directory:

1. Open your FTP connection to the Worldpay outbound directory.
2. Locate the response file, which will have the same name as the file you submitted. If the response file
has a .prg extension, it is still transferring. The extension changes to .asc when the transfer to the
outbound directory completes.
3. Retrieve the response file.

NOTE: Worldpay removes response files from the outbound directory after 24 hours. Plan to
retrieve your files daily.

2.3.2 Transferring Online Files

The recommended method for submitting Online transactions is via HTTPS POST. The sections that
follow provide examples of ASP and Java programming methods for submitting your data using HTTPS
POST.
• ASP Programming Example
• Java Programming Example
• Helpful Web Sites

NOTE: Before you begin testing, Worldpay provides the test system URL, a username/password,
and any additional information required to test your XML transactions.

2.3.2.1 ASP Programming Example

The following code is an example of a cnpAPI Authorization transaction submitted via HTTPS Post using
ASP.
Dim xml
Dim strXML
strXML = strXML & "<cnpOnlineRequest version=""12.0""
xmlns=""http://www.vantivcnp.com/schema"" merchantId=""MERCHANTID"">"
strXML = strXML & "<authentication>"
strXML = strXML & "<user>USERNAME</user>"
strXML = strXML & "<password>########</password>"
strXML = strXML & "</authentication>"
strXML = strXML & "<authorization id=""834262"" reportGroup=""123""
customerId=""038945"">"

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

89
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

strXML = strXML & "<orderId>3235059</orderId>"

strXML = strXML & "<amount>54399</amount>"
strXML = strXML & "<orderSource>ecommerce</orderSource>"
strXML = strXML & "<billToAddress>"
strXML = strXML & "<name>Todd Wilson</name>"
strXML = strXML & "<addressLine1>123 Blue Street</addressLine1>"
strXML = strXML & "<addressLine2>Suite 108</addressLine2>"
strXML = strXML & "<addressLine3>Address Line 3</addressLine3>"
strXML = strXML & "<city>Lowell</city>"
strXML = strXML & "<state>MA</state>"
strXML = strXML & "<zip>01851</zip>"
strXML = strXML & "<country>USA</country>"
strXML = strXML & "<email>[email protected]</email>"
strXML = strXML & "<phone>323-222-2222</phone>"
strXML = strXML & "</billToAddress>"
strXML = strXML & "<card>"
strXML = strXML & "<type>VI</type>"
strXML = strXML & "<number>#############</number>"
strXML = strXML & "<expDate>0521</expDate>"
strXML = strXML & "<cardValidationNum>###</cardValidationNum>"
strXML = strXML & "</card>"
strXML = strXML & "</authorization>"
strXML = strXML & "</cnpOnlineRequest>"
set xml = CreateObject("Microsoft.XMLHTTP")
xml.setRequestHeader "Content-type", "text/xml; charset=UTF-8"
xml.Open "POST", "https://site.info.com/from_Vantiv", False
xml.Send strXML
Response.write (xml.responseText)
set xml = Nothing

2.3.2.2 Java Programming Example

The following is an example of Java code used for HTTPS Post.

PostMethod and HttpClient are both part of the Apache HttpClient library
located at http://jakarta.apache.org/commons/httpclient/.

PostMethod post = new PostMethod(url); // url = fully qualified url of the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

90
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

server to which you are posting

post.setRequestHeader("Content-type", "text/xml; charset=UTF-8");
post.setRequestBody(data); //data = request data in XML format

HttpClient client = new HttpClient();

client.setTimeout(10000); //10 second timeout (in milliseconds) is
suggested minimum, 30 second recommended for alternate payment methods
client.executeMethod(post);

String response = post.getResponseBodyAsString();

//if the server throws an exception you get a null response

//to get around this set it to ""
if (response == null) {
response = "";
}
post.releaseConnection();

2.3.2.3 Notes on Timeout Settings

While Worldpay optimizes our systems to ensure the return of Authorization responses as quickly as
possible, some portions of the process are beyond our control. The round-trip time of an Authorization
can be broken down into three parts, as follows:
1. Transmission time (across the Internet) to Worldpay and back to the merchant
2. Processing time by the card association or authorization provider
3. Processing time by Worldpay
Typically, the transmission time to and from Worldpay does not exceed 0.6 seconds and processing time
by Worldpay occurs in 0.1 seconds. The processing time by the card association or authorization provider
can take between 0.5 and 3 seconds, but some percentage of transactions may take significantly longer.
Because the total processing time can vary due to a number of factors, Worldpay recommends using a
timeout setting of 10 seconds minimum for card transactions and 30 seconds minimum for alternate
payment methods. These settings should ensure that you do not disconnect prior to receiving a valid
authorization, causing dropped orders and/or re-auths and duplicate auths.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

91
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: While it is uncommon, under certain circumstances network latency may cause a duplicate
Online Sale transaction to go undetected as a duplicate. This can occur if you submit a second,
duplicate Sale transaction while the response from the network for the Authorization portion of the
first transaction is sufficiently delayed such that the first Sale has not been recorded as a valid
transaction in the system.
If you elect to submit Online Sale transactions, Worldpay recommends a timeout setting of not less
than 60 seconds to reduce the chances of undetected duplicate Sale transactions.

2.3.2.4 Notes on Persistent Connections

In order to provide a highly scalable service that meets the needs of high-throughput merchants, while
reducing the number of idle connections that could result in some merchants exceeding their connection
limits, Worldpay systems allow for 10 seconds of idle time before closing a connection. We selected this
value because it is the midpoint between the Apache httpd 2.0 default value of 15 seconds and the
Apache 2.2 default value of 5 seconds. Also, HTTP/1.1, which most modern HTTP client libraries use,
employ persistent connections by default. When using a persistent connection, please keep the 10
second idle time limit in mind, when coding. If you do not use persistent connections, to avoid connection
limit issues, please validate that your default configuration closes connections after each request.

NOTE: Proper use of persistent connections is considerably faster than opening and closing
connections with each request.

2.3.2.5 Helpful Web Sites

The following web sites provide additional information, helpful hints, and examples of different
programming methods used in combination with HTTPS POST.
• http://p2p.wrox.com
• http://en.allexperts.com/q/Active-Server-Pages-1452/XML-ASP-Parser-2.htm
• http://www.java-samples.com/java/POST-toHTTPS-url-free-java-sample-program.htm

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

92
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.4 Performing the Required Certification Tests

You are required to complete a number of certification tests prior to submitting real transactions to the
Worldpay production system. This testing process allows you to verify that your system not only submits
correctly formatted transaction data, but also correctly parses the data returned to you in the response
messages. To facilitate the certification process, Worldpay established a certification environment that
simulates the production environment.

IMPORTANT: To determine the final status and response Code of a declined or duplicate
transactions, please refer to the Declined Transaction Report in the Worldpay eComm iQ. Once in
the production environment, you can also obtain this daily report via Secure Scheduled Reports.

During certification testing, a Worldpay Implementation Consultant will guide you through each required
test scenario. For each transaction type specific data is supplied that you must use in your cnpAPI
transactions. Use of this data allows the validation of your transaction structure/syntax, as well as the
return of a response file containing known data.

NOTE: The test data supplied does not account for all data fields/XML elements in a particular
request. Where data is not supplied, you should provide appropriate information. You should never
override your own system to enter supplied data. If you are unable to enter the supplied data without
overriding your system, please consult your Implementation Consultant concerning the test and how
to proceed.
Never use the supplied test data in the production environment.

2.4.1 Testing Authorization (including Indicators), AVS Only, Capture,

Credit, Sale, and Void Transactions

NOTE: To test your handling of 2-series (BIN) number for Mastercard, you can substitute a 2-series
test card number (see Appendix C, "Test Card Numbers") in any Auth/Sale test and you will receive
a 000 - Approved Response Code in the response message.

Table 2-1 provides 26 data sets you use to test your construction of Authorization, AVS Only, Sale and
Force Capture transactions, as well as your ability to parse the information contained in the XML
response messages. You also use some of the approved authorizations as the basis for testing Capture
and Credit transactions.
You do not necessarily have to perform all Authorization test. The tests you perform depend upon the
Worldpay features you have elected to use. The tests are divided as follows:
• Order Ids 1 through 9 - used to test standard Authorization requests and responses. Also used for
AVS Only test and Sale test. (Capture test use the cnpTxnId returned in the response messages.)
• Order Ids 10 through 13 - include if you plan to use Partial Authorization
• Order Ids 14 and 20 - include if you plan to use the Prepaid Indicator feature (see Prepaid Indicator
on page 24)
• Order Ids 21 through 24 - include if you plan to use the Affluence Indicator feature (see Affluence
Indicator on page 25)

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

93
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

• Order Id 25 - include if you plan to use the Issuer Country feature (see Issuer Country Indicator on
page 25)
To test Authorization transactions:
1. Verify that your Authorization XML template is coded correctly (refer to Authorization Transactions on
page 198.)
2. Submit authorization transactions using the data shown in the Supplied Data Elements of Order
Ids 1 through 9 of Table 2-1.
3. Verify that your response values match those shown in Key Response Elements for Order Ids 1
through 9 as shown in Table 2-1.
4. If you wish to test AVS only transactions, re-submit Order Ids 1 through 5, 7, 8, and 9 (skip order 6),
but substitute 000 for the amount. The AVS result returned will be the value shown in the Key
Response Elements section.

NOTE: Some Issuers do not return an Auth Code for $0 Authorizations. You should code your
systems to handle this possibility.

5. If you plan to use Partial Authorizations, submit authorization transactions using the data
shown in the Supplied Data Elements of Order Ids 10 through 13 of Table 2-1.
6. Verify that your response values match those shown in Key Response Elements for Order Ids 10
through 13 as shown in Table 2-1.
7. If you elected to receive Prepaid Indicators, submit authorization transactions using the data
shown in the Supplied Data Elements of Order Ids 14 through 20 of Table 2-1. Verify that your
response values match those shown in Key Response Elements for Order Ids 14 and 15 as shown in
Table 2-1.
8. If you elected to receive Affluence Indicators, submit authorization transactions using the data
shown in the Supplied Data Elements of Order Ids 21through 24 of Table 2-1. Verify that your
response values match those shown in Key Response Elements for Order Ids 16 through 19 as
shown in Table 2-1.
9. If you elected to receive Issuer Country information, submit an authorization transaction using
the data shown in the Supplied Data Elements of Order Id 25 of Table 2-1. Verify that your response
values match those shown in Key Response Elements for Order Id 25 as shown in Table 2-1.
10. If you elected to receive Issuer Insights data, submit an authorization transaction using the data
shown in the Supplied Data Elements of Order Id IssuerInsights of Table 2-1. Verify that your
response values match those shown in Key Response Elements for Order Id 25 as shown in
Table 2-1. This data includes the accountRangeId element in the response message.
11. If you plan to handle transactions using Healthcare (IIAS) cards, submit authorization
transactions using the data shown in the Supplied Data Elements of Order Ids 26 through 31A of
Table 2-1. Verify that your response values match those shown in Key Response Elements for Order
Ids 26 through 31 as shown in Table 2-1.
To Test Sale transactions:
1. Verify that your Sale XML template is coded correctly (refer to Sale Transactions on page 300.)
2. Submit sale transactions using the data shown in the Supplied Data Elements of Order Ids 1 through
9 of Table 2-1.
3. Verify that your response values match those shown in Key Response Elements for Order Ids 1
through 9 as shown in Table 2-1.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

94
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

To Test Capture transactions:

1. Verify that your Capture XML template is coded correctly (refer to Capture Transactions on page
220.).
2. Submit capture transactions for Order Ids 1A through 5A using the cnpTxnId value returned in the
response messages for Authorization Order Ids 1 through 5.
3. Verify that your response values match those shown in Key Response Elements for Order Ids 1A
through 5A as shown in Table 2-1.
To test Credit transactions:
1. Verify that your Credit XML template is coded correctly (refer to Credit Transactions on page 235.)
2. Submit credit transactions for Order Ids 1B through 5B using the cnpTxnId value returned in the
response messages for Capture Order Ids 1A through 5A.
3. Verify that your response values match those shown in Key Response Elements for Order Ids 1B
through 5B as shown in Table 2-1.
To test Void transactions (in this test you have the option of voiding either Credit or Sale transactions):
1. Verify that your Void XML template is coded correctly (refer to Void Transactions (Online Only) on
page 319.)
2. Submit void transactions for Order Ids 1C through 5C (and 6Bif voiding Sale transactions) using the
cnpTxnId value returned in either the response messages for Credit Order Ids 1B through 5B, or the
response messages for Sale (not Auth) Order Id 1 through 6.
3. Verify that your response values match those shown in Key Response Elements for Order Ids 1C
through 5C (include 6B only if you elect to void the Sales transactions) as shown in Table 2-1.

TABLE 2-1 Authorization Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

1 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 000
<name> John & Mary Smith <message> Approved
<addressLine1> 1 Main St. <authCode> 11111
<city> Burlington <avsResult> 01
<state> MA <cardValidationResult> M
<zip> 01803-3747
<country> US
<type> VI
<number> 4457010000000009
<expDate> 0121
<cardValidationNum> 349

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

95
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

1A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 1

1B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response
<message> Approved
for Order Id 1A

1C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the <message> Approved
Credit response for
Order Id 1B, or the
value returned in
the Sale response
(not Auth) for Order
Id 1.

2 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 000
<name> Mike J. Hammer <message> Approved
<addressLine1> 2 Main St. <authCode> 22222
<addressLine2> Apt. 222 <avsResult> 10
<city> Riverside <cardValidationResult> M
<state> RI <authenticationResult> Note: Not returned
<zip> 02915 for Mastercard

<country> US
<type> MC
<number> 5112010000000003
<expDate> 0221
<cardValidationNum> 261
<authenticationValue> BwABBJQ1AgAAA
AAgJDUCAAAAAA
A=

2A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 2

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

96
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

2B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response <message> Approved
for Order Id 2A

2C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the
<message> Approved
Credit response for
Order Id 2B, or the
value returned in
the Sale response
(not Auth) for Order
Id 2.

3 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 000
<name> Eileen Jones <message> Approved
<addressLine1> 3 Main St. <authCode> 33333
<city> Bloomfield <avsResult> 10
<state> CT <cardValidationResult> M
<zip> 06002
<country> US
<type> DI
<number> 6011010000000003
<expDate> 0321
<cardValidationNum> 758

3A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for
<message> Approved
Order Id 3

3B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response <message> Approved
for Order Id 3A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

97
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

3C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the <message> Approved
Credit response for
Order Id 3B, or the
value returned in
the Sale response
(not Auth) for Order
Id 3.

4 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 000
<name> Bob Black <message> Approved
<addressLine1> 4 Main St. <authCode> 44444
<city> Laurel <avsResult> 13
<state> MD
<zip> 20708
<country> US
<type> AX
<number> 375001000000005
<expDate> 0421

4A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 4

4B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response <message> Approved
for Order Id 4A

4C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the <message> Approved
Credit response for
Order Id 4B, or the
value returned in
the Sale response
(not Auth) for Order
Id 4.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

98
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

5 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 000
<type> VI <message> Approved
<number> 4100200300011001 <authCode> 55555
<expDate> 0521 <avsResult> 32
<cardValidationNum> 463 <cardValidationResult> M
<authenticationValue> BwABBJQ1AgAAA
AAgJDUCAAAAAA
A=

5A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 5

5B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response <message> Approved
for Order Id 5A

5C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the
<message> Approved
Credit response for
Order Id 5B, or the
value returned in
the Sale response
(not Auth) for Order
Id 5.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

99
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

6 Authorization/Sale: Authorization Response:

<amount> 10100 <response> 110
<name> Joe Green <message> Insufficient Funds
<addressLine1> 6 Main St. <avsResult> 34
<city> Derry <cardValidationResult> P
<state> NH
<zip> 03038
<country> US
<type> VI
<number> 4457010100000008
<expDate> 0621
<cardValidationNum> 992

6A Void: Void Response:

<cnpTxnId> Use the value <response> 000
returned in the Sale <message> Approved
response (not Auth)
for Order Id 6.
Declined Transaction report
result = 360 - No
transaction found with
specified cnpTxnId

7 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 301
<name> Jane Murray Invalid Account
<message> Number
<addressLine1> 7 Main St.
<avsResult> 34
<city> Amesbury
<cardValidationResult> N
<state> MA
<zip> 01913
<country> US
<type> MC
<number> 5112010100000002
<expDate> 0721
<cardValidationNum> 251

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

100
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

8 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 123
<name> Mark Johnson <message> Call Discover
<addressLine1> 8 Main St. <avsResult> 34
<city> Manchester <cardValidationResult> P
<state> NH
<zip> 03101
<country> US
<type> DI
<number> 6011010100000002
<expDate> 0821
<cardValidationNum> 184

9 Authorization/Sale/AVS: Authorization Response:

<amount> 10100 <response> 303
<name> James Miller <message> Pick Up Card
<addressLine1> 9 Main St. <avsResult> 34
<city> Boston <cardValidationResult> P
<state> MA
<zip> 02134
<country> US
<type> AX
<number> 375001010000003
<expDate> 0921
<cardValidationNum> 0421

NOTE: The data sets for orderId 10 through 13 are designed to test Authorization transactions resulting in
partial authorizations. If you are not coding to use partial authorizations, you may skip these tests.

10 <amount> 40000 <response> 010

<type> VI <message> Partially Approved
<number> 4457010140000141 <approvedAmount> 32000
<expDate> 0921
<allowPartialAuth> true

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

101
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

11 <amount> 60000 <response> 010

<type> MC <message> Partially Approved
<number> 5112010140000004 <approvedAmount> 48000
<expDate> 1121
<allowPartialAuth> true

12 <amount> 50000 <response> 010

<type> AX <message> Partially Approved
<number> 375001014000009 <approvedAmount> 40000
<expDate> 0421
<allowPartialAuth> true

13 <amount> 15000 <response> 010

<type> DI <message> Partially Approved
<number> 6011010140000004 <approvedAmount> 12000
<expDate> 0821
<allowPartialAuth> true

NOTE: The data sets for orderId 14 through 20 are designed to test Authorization transactions that return
Prepaid Indicator information in the response message. If you are not coding to use the optional Prepaid
Indicator feature of the Insights feature set, you may skip these tests.

14 <amount> 10100 <response> 000

<type> VI <message> Approved
<number> 4457010200000247 <type> PREPAID
<expDate> 0821 <availableBalance> 2000
<reloadable> NO
<prepaidCardType> GIFT

15 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5500000254444445 <type> PREPAID
<expDate> 0321 <availableBalance> 2000
<reloadable> YES
<prepaidCardType> PAYROLL

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

102
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

16 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5592106621450897 <type> PREPAID
<expDate> 0321 <availableBalance> 0
<reloadable> YES
<prepaidCardType> PAYROLL

17 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5590409551104142 <type> PREPAID
<expDate> 0321 <availableBalance> 6500
<reloadable> YES
<prepaidCardType> PAYROLL

18 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5587755665222179 <type> PREPAID
<expDate> 0321 <availableBalance> 12200
<reloadable> YES
<prepaidCardType> PAYROLL

19 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5445840176552850 <type> PREPAID
<expDate> 0321 <availableBalance> 20000
<reloadable> YES
<prepaidCardType> PAYROLL

20 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5390016478904678 <type> PREPAID
<expDate> 0321 <availableBalance> 10050
<reloadable> YES
<prepaidCardType> PAYROLL

NOTE: The data sets for orderId 21 through 24 are designed to test Authorization transactions that return
Affluence Indicator information in the response message. If you are not coding to use the optional Affluence
Indicator feature of the Insights feature set, you may skip these tests.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

103
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

21 <amount> 10100 <response> 000

<type> VI <message> Approved
<number> 4100200300012009 <affluence> AFFLUENT
<expDate> 0921

22 <amount> 10100 <response> 000

<type> VI <message> Approved
<number> 4100200300013007 <affluence> MASS AFFLUENT
<expDate> 1121

23 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5112010201000109 <affluence> AFFLUENT
<expDate> 0421

24 <amount> 10100 <response> 000

<type> MC <message> Approved
<number> 5112010202000108 <affluence> MASS AFFLUENT
<expDate> 0821

NOTE: The data set for orderId 25 is designed to test Authorization transactions that return Issuer Country
information in the response message. If you are not coding to use the optional Issuer Country feature of the
Insights feature set, you may skip these tests.

25 <amount> 10100 <response> 000

<type> VI <message> Approved
<number> 4100200310000002 <issuerCountry> BRA
<expDate> 1121

NOTE: The data set for orderId IssuerInsights is designed to test Authorization transactions that return an
Account Range Id in the response message.

IssuerI <amount> 12789 <response> 000

nsights
<type> VI <message> Approved
<number> 4457010200000247 <accountRangeId> 108
<expDate> 1121

NOTE: The data sets for orderId 26 through 31A are designed to test Authorization transactions involving
Healthcare Care (IIAS) transaction. If you are not coding to perform Healthcare Care (IIAS) transactions, you
may skip these tests.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

104
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

26 <amount> 18698 <response> 341

<type> MC <message> Invalid healthcare
amounts
<number> 5194560012341234
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 20000

27 <amount> 18698 <response> 341

<type> MC <message> Invalid healthcare
amounts
<number> 5194560012341234
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 15000
<RxAmount> 16000

28 <amount> 15000 <response> 000

<type> MC <message> Approved
<number> 5194560012341234
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 15000
<RxAmount> 3698

29 <amount> 18699 <response> 341

<type> VI <message> Invalid healthcare
amounts
<number> 4024720001231239
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 31000
<RxAmount> 20910
<visionAmount> 1000
<clinicOtherAmount> 9050
<dentalAmount> 1049

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

105
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-1 Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

30 <amount> 20000 <response> 341

<type> VI <message> Invalid healthcare
amounts
<number> 4024720001231239
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 20000
<RxAmount> 20901
<visionAmount> 1000
<clinicOtherAmount> 9050
<dentalAmount> 1049

31 <amount> 40000 <response> 010

<type> VI <message> Partially Approved
<number> 4024720001231239 <approvedAmount> 18689
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 18699
<RxAmount> 1000
<visionAmount> 15099
<clinicOtherAmount> 17699

31A <amount> 6000 <response> 000

<type> VI <message> Approved
<number> 4024720001231239
<expDate> 1221
<allowPartialAuth> true
<totalHealthcareAmount> 5000
<RxAmount> 5000
<visionAmount> 1000

2.4.2 Testing Authorization Reversal Transactions

If you plan to use Authorization Reversal Transactions, you must perform this test. If you do not plan to
use Authorization Reversal transactions, skip this test and go to Testing Direct Debit Transactions on
page 110.
To test Authorization Reversal Transactions:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

106
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

1. Verify that your Authorization Reversal XML templates are coded correctly (refer to Authorization
Reversal Transactions on page 210).
2. Submit the Authorizations, Captures (if applicable), and Authorization Reversal Transactions using
the orders shown in Table 2-2.
3. Verify that your response values match those shown in Key Response Elements as shown in
Table 2-2.

TABLE 2-2 Authorization Reversal Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

32 Authorization: Authorization Response:

<amount> 10010 <response> 000
<name> John Smith <message> Approved
<addressLine1> 1 Main St. <authCode> 11111
<city> Burlington <avsResult> 01
<state> MA <cardValidationResult> M
<zip> 01803-3747
<country> US
<type> VI
<number> 4457010000000009
<expDate> 0121
<cardValidationNum> 349

32A Capture: Capture Response:

<amount> 5050 <response> 000
<cnpTxnId> Value returned in <message> Approved
Auth response for
Order Id 32

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

107
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-2 Authorization Reversal Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

32B Authorization Reversal: Auth Reversal Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 32
<amount> Do Not Submit an
Amount Declined Transaction report
result = 111 - Authorization
amount has already been
depleted
Note: This transaction
returns 111 instead of 000,
because it is unnecessary
to submit an Authorization
Reversal for the Visa
payment card.

33 Authorization: Authorization Response:

<amount> 20020 <response> 000
<name> Mike J. Hammer <message> Approved
<addressLine1> 2 Main St. <authCode> 22222
<addressLine2> Apt. 222 <avsResult> 10
<city> Riverside <cardValidationResult> M
<state> RI <authenticationResult> Note: Not returned
for Mastercard
<zip> 02915
<country> US
<type> MC
<number> 5112010000000003
<expDate> 0221
<cardValidationNum> 261
<authenticationValue> BwABBJQ1AgAAA
AAgJDUCAAAAAA
A=

33A Authorization Reversal: Auth Reversal Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 33
<amount> Do Not Submit an
amount

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

108
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-2 Authorization Reversal Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

34 Authorization: Authorization Response:

<amount> 30030 <response> 000
<name> Eileen Jones <message> Approved
<addressLine1> 3 Main St. <authCode> 33333
<city> Bloomfield <avsResult> 10
<state> CT <cardValidationResult> M
<zip> 06002
<country> US
<type> DI
<number> 6011010000000003
<expDate> 0321
<cardValidationNum> 758

34A Authorization Reversal: Auth Reversal Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 34
<amount> Do Not Submit an
Amount

35 Authorization: Authorization Response:

<amount> 10100 <response> 000
<name> Bob Black <message> Approved
<addressLine1> 4 Main St. <authCode> 44444
<city> Laurel <avsResult> 13
<state> MD
<zip> 20708
<country> US
<type> AX
<number> 375001000000005
<expDate> 0421

35A Capture: Capture Response:

<amount> 5050 <response> 000
<cnpTxnId> Value returned in <message> Approved
Auth response for
Order Id 35

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

109
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-2 Authorization Reversal Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

35B Authorization Reversal: Auth Reversal Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 35
Declined Transaction report
<amount> 5050 result = 336 - Reversal
amount does not match
Authorization amount

36 Authorization: Authorization Response:

<amount> 20500 <response> 000
<type> AX <message> Approved
<number> 375000026600004
<expDate> 0521

36A Authorization Reversal: Auth Reversal Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id 36
<amount> 10000
Declined Transaction report
result = 336 - Reversal
amount does not match
Authorization amount

2.4.3 Testing Direct Debit Transactions

If you have elected to offer Direct Debits as an alternate payment method, you are required to complete
the tests in this section. Data sets are provided for you to use to test your construction of XML request
messages, as well as the parsing of the response messages for Direct Debit transactions.

NOTE: The eCheck Verification test is required only if you plan to perform eCheck Verifications.

To test eCheck Verification transactions:

1. Verify that your XML template is coded correctly (refer to eCheck Verification Transactions on page
264.)
2. Submit the eCheck Verification transactions using the data sets supplied in Table 2-3.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

110
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: In addition to the test data provided in the table, you must also provide appropriate data for
other child elements of the billToAddress element, such as Address1 (2, 3), city, state,
phone, etc.
For Corporate accounts (Order ID 39 and 40) you must include the firstName, lastName, and
companyName in the echeckVerification request.

3. Verify that your response values match those shown in the Key Response Elements section of
Table 2-3.
4. After you complete this test, go to the next Direct Debit test.

TABLE 2-3 eCheck Verification Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

37 <amount> 3001 <response> 301

<orderSource> telephone <message> Invalid Account
Number
<firstName> Tom
<lastName> Black
<accType> Checking
<accNum> 10@BC99999
<routingNum> 053100300

38 <amount> 3002 <response> 000

<orderSource> telephone <message> Approved
<firstName> John
<lastName> Smith
<accType> Checking
<accNum> 1099999999
<routingNum> 011075150

39 <amount> 3003 <response> 950

<orderSource> telephone <message> Declined -
Negative
<firstName> Robert
Information on File
<lastName> Jones
<companyName> Good Goods Inc
<accType> Corporate
<accNum> 3099999999
<routingNum> 053100300

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

111
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-3 eCheck Verification Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

40 <amount> 3004 <response> 951

<orderSource> telephone <message> Absolute Decline
<firstName> Peter
<lastName> Green
<companyName> Green Co
<accType> Corporate
<accNum> 8099999999
<routingNum> 011075150

To test eCheck Prenotification transactions:

NOTE: The eCheck Prenotification tests are required only if you plan to perform eCheck
Prenotification.
You can only submit eCheck Prenotification transactions in Batches.

1. Verify that your XML templates are coded correctly (refer to eCheck Prenotification Credit
Transactions (Batch Only) on page 254 and eCheck Prenotification Sale Transactions (Batch Only)
on page 256.)
2. Submit the eCheck Verification transactions using the data sets supplied in Table 2-4.
3. Verify that your response values match those shown in the Key Response Elements section of
Table 2-4.
4. After you complete this test, go to the next Direct Debit test.

TABLE 2-4 eCheck Prenotification Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

ECPreNoteSale <orderSource> ecommerce <response> 000

<name> PreNote Sale Corp <message> Approved
<accType> Corporate
<accNum> 1092969901
<routingNum> 011075150

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

112
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-4 eCheck Prenotification Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

ECPreNoteCredit <orderSource> ecommerce <response> 000

<name> PreNote Credit Corp <message> Approved
<accType> Corporate
<accNum> 1099339999
<routingNum> 011075150

PreNoteSaleAccN <orderSource> ecommerce <response> 301

umErr
<name> PreNote Sale Corp <message> Invalid Account
Number
<accType> Corporate
<accNum> 10@2969901
<routingNum> 011100012

PreNoteCreditAcc <orderSource> ecommerce <response> 301

NumErr
<name> PreNote Credit <message> Invalid Account
Personal Number
<accType> Savings
<accNum> 10@2969901
<routingNum> 011100012

PreNoteSaleRoutN <orderSource> ecommerce <response> 900

umErr
<name> PreNote Sale <message> Invalid Bank
Personal Routing Number
<accType> Checking
<accNum> 6099999992
<routingNum> 053133052

PreNoteCreditRout <orderSource> ecommerce <response> 900

NumErr
<name> PreNote Credit <message> Invalid Bank
Personal Routing Number
<accType> Checking
<accNum> 6099999992
<routingNum> 053133052

To test eCheck Sale transactions:

1. Verify that your XML template is coded correctly (refer to eCheck Sale Transactions on page 261).
2. Submit the echeckSale transactions using the Supplied Data elements shown in Table 2-5.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

113
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: In addition to the test data provided in the table, you must also provide appropriate data for
other child elements of the billToAddress element, such as Address1 (2, 3), city, state,
phone, etc.

3. Verify that your response values match those shown in Table 2-5.
4. After you complete this test, go to the next test.

TABLE 2-5 eCheck Sale Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

41 <amount> 2008 <response> 301

<orderSource> telephone <message> Invalid Account
Number
<name> Mike Hammer
<firstName> Mike
<middleInitial> J
<lastName> Hammer
<accType> Checking
<accNum> 10@BC99999
<routingNum> 053100300

42 <amount> 2004 <response> 000

<orderSource> telephone <message> Approved
<name> Tom Black
<firstName> Tom
<lastName> Black
<accType> Checking
<accNum> 4099999992
<routingNum> 011075150

43 <amount> 2007 <response> 000

<orderSource> telephone <message> Approved
<name> Peter Green Note: If you are
enabled to receive
<firstName> Peter
AU information,
<lastName> Green this response will
<companyName> Green Co include the
accountUpdater
<accType> Corporate element (see
<accNum> 6099999992 accountUpdater on
page 334).
<routingNum> 011075150

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

114
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-5 eCheck Sale Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

44 <amount> 2009 <response> 900

<orderSource> telephone <message> Invalid Bank
Routing Number
<name> Peter Green
<firstName> Peter
<lastName> Green
<companyName> Green Co
<accType> Corporate
<accNum> 9099999992
<routingNum> 053133052

To test eCheck Credit transactions:

1. Verify that your XML template is coded correctly (refer to eCheck Credit Transactions on page 251.)

NOTE: In addition to the test data provided in the table, you must also provide appropriate data for
other child elements of the billToAddress element, such as Address1 (2, 3), city, state,
phone, etc.

2. Submit the echeckCredit transactions using the data in the Supplied Data Elements section of
Table 2-6.
3. Verify that your response values match those shown in the Key Response Elements section of
Table 2-6.
4. After you complete this test, go to the next test.

TABLE 2-6 eCheck Credit Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

45 <amount> 1001 <response> 301

<orderSource> telephone <message> Invalid Account
Number
<name> John Smith
<firstName> John
<lastName> Smith
<accType> Checking
<accNum> 10@BC99999
<routingNum> 053100300

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

115
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-6 eCheck Credit Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

46 <amount> 1003 <response> 000

<orderSource> telephone <message> Approved
<name> Robert Jones
<firstName> Robert
<lastName> Jones
<companyName> Widget Inc
<accType> Corporate
<accNum> 3099999999
<routingNum> 011075150

47 <amount> 1007 <response> 000

<orderSource> telephone <message> Approved
<name> Peter Green Note: This
response will
<firstName> Peter
include the
<lastName> Green accountUpdater
<companyName> Green Co element (see
accountUpdater on
<accType> Corporate page 334.)
<accNum> 6099999993
<routingNum> 211370545

48 <cnpTxnId> Value returned in <response> 000

eCheck Sale
<message> Approved
response for Order
Id 43

49 <cnpTxnId> 2 <response> 000

<message> Approved

Declined Transaction
report result = 360 - No
transaction found with
specified cnpTxnId

To test eCheck Void transactions:

1. Verify that your eCheck XML template is coded correctly (refer to eCheck Void Transactions (Online
Only) on page 268.)
2. (Re)Submit the echeckSale transaction for Order ID #42 as shown in Table 2-5 with a different
value for the id attribute.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

116
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

a. Using the cnpTxnId returned in the echeckSaleResponse message, submit an echeckVoid

transaction.
b. The system returns an echeckVoidResponse Response Code of 000 and a message of
Approved.
3. Using the cnpTxnId returned in the echeckCreditResponse message for Order ID #46, submit
an echeckVoid transaction.
a. The system returns an echeckVoidResponse Response Code of 000 and a message of
Approved.
4. Submit an echeckVoid request using a value of 2 for the cnpTxnId.
a. The system returns a Response Code of 000 and a message of Approved; however, the Declined
Transaction Report will contain a Response Code of 360 and a message of No transaction found
with specified cnpTxnId for this transaction.
5. After you complete this test, go to the next test.

2.4.4 Testing Token Transactions

You can obtain tokens in two ways. The first method is explicit registration using the
registerTokenRequest transaction. The second method is implicit registration, which is achieved by
submitting the card or account information (for Direct Debits) in a normal payment transaction. This
section provides test data sets using both methods for both credit card and Direct Debit tokenization.
Perform this test only if you plan to use the Vault feature.

NOTE: The test data does not include values for all elements. You should use appropriate values
for all elements as required to create a properly structured cnpAPI request.

To test explicit Token Registration transactions:

1. Verify that your cnpAPI template is coded correctly for this transaction type (refer to Register Token
Transactions on page 292.)
2. To test credit card tokenization, submit registerTokenRequest transactions using the data for
Order Ids 50 through 52 from Table 2-7.
3. If you use Direct Debit transactions and have elected to tokenize Direct Debit account numbers,
submit registerTokenRequest transactions using the data for Order Ids 53 and 54 from
Table 2-7; otherwise, skip those two tests.
4. Verify that your registerTokenResponse values match those shown in the Key Response
Elements section of Table 2-7. The complete token values are not defined in the table, because the
system generates the tokens dynamically.
5. After completing this test, proceed to the next set of tests for implicit tokenization.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

117
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-7 Register Token Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

50 <accountNumber> 4457119922390123 <cnpToken> xxxxxxxxxxxx0123

<bin> 445711
<type> VI
<response> 801
<message> Account number
was successfully
registered

51 <accountNumber> 4457119999999999 <cnpToken> none returned

<response> 820
<message> Credit card number
was invalid

52 <accountNumber> 4457119922390123 <cnpToken> xxxxxxxxxxxx0123

<bin> 445711
<type> VI
<response> 802
<message> Account number
was previously
registered

53 <accNum> 1099999998 <cnpToken> xxxxxxxxxx

<routingNum> 011100012 <type> EC
<eCheckAccountSuffix> 998
<response> 801
<message> Account number
was successfully
registered

54 <accNum> 1022222102 <response> 900

<routingNum> 1145_7895 <message> Invalid bank
routing number

To test the submission of card data in an tokenized environment using Authorization transactions, as well
as the submission of tokens in transactions, do the following:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

118
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

1. Verify that your cnpAPI template is coded correctly for this transaction type (refer to Authorization
Transactions on page 198.)
2. Submit three authorization transactions using the Supplied Data Elements from Order Ids 55
through 57 from Table 2-8.
3. Verify that your authorizationResponse values match those shown in the Key Response
Elements section of Table 2-8 for Order Ids 55 through 57.
4. To verify that your cnpAPI template is coded correctly for the submission of tokens in
authorization transactions, submit authorization transactions using the Supplied Data
Elements from Order Ids 58 through 60 from Table 2-8.
To test the submission of Direct Debit data in an tokenized environment, as well as the submission of
tokens in Direct Debit transactions, do the following:
1. Verify that your cnpAPI template is coded correctly for these transaction types as applicable (refer to
eCheck Sale Transactions on page 261 and eCheck Credit Transactions on page 251).
2. Submit the four transactions, Order Ids 61 through 64, using the Supplied Data Elements from
Table 2-8.
3. Verify that your response values match those shown in the Key Response Elements section of
Table 2-8 for Order Ids 61 through 64.

TABLE 2-8 Implicit Registration Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

55 <amount> 15000 <response> 000

<type> MC <message> Approved
<number> 5435101234510196 <cnpToken> xxxxxxxxxxxx0196
<expDate> 1121 <tokenResponseCode> 801
<cardValidationNum> 987 <tokenMessage> Account number was
successfully
registered
<type> MC
<bin> 543510

56 <amount> 15000 <<response> 301

<type> MC <message> Invalid account
number
<number> 5435109999999999
<expDate> 1121
<cardValidationNum> 987

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

119
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-8 Implicit Registration Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

57 <amount> 15000 <response> 000

<type> MC <message> Approved
<number> 5435101234510196 <cnpToken> xxxxxxxxxxxx0196
<expDate> 1121 <tokenResponseCode> 802
<cardValidationNum> 987 <tokenMessage> Account number was
previously registered
<type> MC
<bin> 543510

58 <amount> 15000 <response> 000

<cnpToken> xxxxxxxxxxxx0196 <message> Approved
<expDate> 1121
<cardValidationNum> 987
Note: Use the token
returned in Order Id
57.

59 <amount> 15000 <response> 822

<cnpToken> 1111000100092332 <message> Token was not found
<expDate> 1121

61 eCheck Sale: <cnpToken> xxxxxxxxxxxxxxxxx

<accType> Checking <tokenResponseCode> 801
<accNum> 1099999003 <tokenMessage> Account number was
successfully
<routingNum> 011100012
registered
<type> EC
<eCheckAccountSuffix> 003

62 eCheck Sale: <cnpToken> xxxxxxxxxxxxxxxxx

<accType> Checking <tokenResponseCode> 801
<accNum> 1099999999 <tokenMessage> Account number was
successfully
<routingNum> 011100012
registered
<type> EC
<eCheckAccountSuffix> 999

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

120
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-8 Implicit Registration Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

63 eCheck Credit: <cnpToken> xxxxxxxxxxxxxxxxx

<accType> Checking <tokenResponseCode> 801
<accNum> 1099999999 <tokenMessage> Account number was
successfully
<routingNum> 011100012
registered
<type> EC
<eCheckAccountSuffix> 999

64 eCheck Sale: <originalTokenInfo> (parent element)

<accType> Corporate <accType> Checking
<accNum> 6099999993 <cnpToken> 11190000001003001
<routingNum> 211370545 <routingNum> 211370545
<newTokenInfo> (parent element)
<accType> Checking
<cnpToken> 11190000001154101
<routingNum> 211370545
<cnpToken> xxxxxxxxxxxxxxxxx
<tokenResponseCode> 801
<tokenMessage> Account number was
successfully
registered
<type> EC
<eCheckAccountSuffix> 993

NOTE: Order ID 64 returns accountUpdater information. This test allows you to test responses you
might receive when a NOC exists against the Direct Debit account, but you submit the old account
information. In this case, the system provides the old token information, but issues a new token
based upon the new account information and provides it as well.

2.4.5 Testing Query Transactions

You can use the following test scenarios to verify your coding of the queryTransaction, as well as
various responses. To test the query transaction, please do the following:

NOTE: If you are enabled for the use of the queryTransaction, you will not be able to test for
response code 153 - Query Transaction not enabled.

1. Submit a queryTransaction with the following elements:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

121
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

• <origId>newTransaction</origId> (Note: You can use any value never used as an id

attribute.)
• <origActionType>A</origActionType> (Note: You can use any valid action type as
detailed in the enumerations table of origActionType on page 633.)
Verify that you receive a response value of 151 and message of Original transaction not found.
2. Submit an authorization or sale transaction using a unique id attribute.
3. Submit a queryTransaction using the id attribute value from Step 2 as the value for the
<origId> element and the <origActionType> element set to the transaction type you submitted
in Step 2.
Verify that you receive a response value of 150 and message of Original transaction found, a
<matchCount> value of 1, and the response message for the transaction submitted in Step 2, as a
child of the <result_Max10> element.
4. Submit a second authorization or sale transaction (use the same transaction type as Step 2),
using the same value for the id attribute. Note: If you use a sale transaction for this test, you must
change the credit card number from the one you used in Step 2 to avoid having the transaction
flagged as a duplicate.
5. Submit a queryTransaction using the id attribute value from Step 2 as the value for the
<origId> element and the <origActionType> element set to the transaction type you submitted
in Step 2.
Verify that you receive a response value of 150 and message of Original transaction found, a
<matchCount> value of 2, and the response messages for the transactions submitted in Steps 2 and
4, as a children of the <result_Max10> element.
6. Submit an authorization or sale transaction using a value of error_id for the id attribute.
7. Submit a queryTransaction using error_id for the origId value.
Verify that you receive a response value of 152 and message of Original transaction found but
response not yet available, a <matchCount> value of 1, and the
<queryTransactionUnavailableResponse> element as a child of the <result_Max10>
element.

2.4.6 Testing Stored Credentials Processing

When you submit the first transaction in a recurring/installment stream, or when storing credentials for
future purchases, you must set the <processingType> element to either initialRecurring,
initialInstallment, or initialCOF (Card on File), as applicable. With the exception of an American Express
transaction, the XML response message includes the <networkTransactionId> element. You must
retain the value returned for use in future transactions. When you submit the next and all subsequent
transactions in the recurring/installment stream, set the <orderSource> to recurring or installment as
appropriate, and include the networkTransactionId value in the
<originalNetworkTransactionId> element. For a CoF transaction, set the <orderSource> to
ecommerce and the <processingType> element to either merchantInitiatedCOF, or
cardholderInitiatedCOF (Card on File), as applicable.
To test recurring/installment and COF transactions, do the following:
1. Submit either Authorization or Sale transactions for orderIds Net_Id1, Net_Id2, and Net_Id3 using the
data shown in Table 2-9. Verify that each transactions response indicates approval and that you
parse and store the value of the networkTransactionId element for each transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

122
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

NOTE: In the Pre-Live environment, the system may return all zeros for the
networkTransactionId.

2. Submit transactions Net_Id1a, Net_Id2a, Net_Id3a and Net_Id3b using the supplied data. Verify that
each transaction results in an approval.

NOTE: Each of the responses include a networkTransactionId value. You can either store this value
for future use in subsequent transactions or continue to use the original value returned in the initial
transactions.

TABLE 2-9 Stored Credentials Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Net_Id1 Authorization/Sale: Authorization Response:

<amount> 4999 <response> 000
<type> VI <message> Approved
<number> 4100200300011001 <networkTransactionId> Dynamically
generated value
<expDate> 0521
<processingType> initialRecurring

Net_Id1a Authorization/Sale: <response> 000

<amount> 4999 <message> Approved
<type> VI
<number> 4100200300011001
<expDate> 0521
<cardValidationNum> 463
<orderSource> recurring
<originalNetworkTrans Value from Net_Id1
actionId> response

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

123
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-9 Stored Credentials Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Net_Id2 Authorization/Sale: Authorization Response:

<amount> 5500 <response> 000
<name> John & Mary Smith <message> Approved
<addressLine1> 1 Main St. <authCode> 11111
<city> Burlington <avsResult> 01
<state> MA <cardValidationResult> M
<zip> 01803-3747 <networkTransactionId> Dynamically
generated value
<country> US
<type> VI
<number> 4457010000000009
<expDate> 0121
<cardValidationNum> 349
<processingType> initialInstallment

Net_Id2a Authorization/Sale: Authorization Response:

<amount> 5500 <response> 000
<type> VI <message> Approved
<number> 4457010000000009
<expDate> 0121
<orderSource> installment
<originalNetworkTrans Value from Net_Id2
actionId> response

Net_Id3 Authorization/Sale: Authorization Response:

<amount> 5500 <response> 000
<name> John Smith <message> Approved
<addressLine1> 1 Main St. <authCode> 654321
<city> Waltham <avsResult> 00
<state> MA <cardValidationResult> P
<zip> 02453 <networkTransactionId> Dynamically
generated value
<country> US
<type> VI
<number> 4457000800000002
<expDate> 0121
<cardValidationNum> 349
<processingType> initialCOF

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

124
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-9 Stored Credentials Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Net_Id3a Authorization/Sale: Authorization Response:

<amount> 2500 <response> 000
<type> VI <message> Approved
<number> 4457000800000002
<expDate> 0121
<orderSource> ecommerce
<processingType> merchantInitiatedCOF
<originalNetworkTrans Value from Net_Id3
actionId> response

Net_Id3b Authorization/Sale: Authorization Response:

<amount> 4000 <response> 000
<type> VI <message> Approved
<number> 4457000800000002
<expDate> 0121
<orderSource> ecommerce
<processingType> cardholderInitiatedCOF

2.4.7 Testing Online Duplicate Transaction Processing

When you submit certain Online transactions, the system acts to detect if it is a duplicate by comparing
the id attribute and the credit card number against other successful Online transactions of the same type
processed within the previous two days. The system performs this checking routine for the following
transaction types: Capture, Force Capture, Capture Given Auth, Credit, Sales, eCheck Credit, eCheck
Sales, eCheckVoid, and Void, as well as Gift Card transactions.
If the system determines a transaction to be a duplicate, The transaction appears in the Declined
Transaction report. This report is available in near real-time via Worldpay eComm iQ, and as an Secure
Scheduled Report, which is generated daily for the previous days transactions. Please refer to Online
Duplicate Checking on page 9 for additional information.
To test your handling of duplicate transactions:

NOTE: When you submit the duplicate transaction, make sure that all information, including the id
attribute, is identical.

1. Send any of the following Capture transactions more than once within a two day period: Order
numbers 1A, 2A, 3A, 4A, or 5A. The second submission will appear in the Declined Transaction
report with a response Reason Code of 251 - Duplicate Transaction. Note: You may have to submit
the corresponding Authorization transaction prior to submitting the Capture transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

125
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2. Send any of the following Credit transactions more than once within a two day period: Order numbers
1B, 2B, 3B, 4B, or 5B. The second submission will appear in the Declined Transaction report with a
response Reason Code of 251 - Duplicate Transaction. Note: You may have to submit the
corresponding Capture transaction prior to submitting the Credit transaction.
3. Send any of the following Void transactions more than once within a two day period: Order numbers
1C, 2C, 3C, 4C, or 5C. The second submission will appear in the Declined Transaction report with a
response Reason Code of 251 - Duplicate Transaction. Note: You may have to submit the
corresponding Sale transaction prior to submitting the Void transaction.
4. Send either of the following eCheck Sale transactions more than once within a two day period: Order
numbers 42 or 43. The second submission will appear in the Declined Transaction report with a
response Reason Code of 251 - Duplicate Transaction.
5. Send any of the following eCheck Credit transactions more than once within a two day period: Order
numbers 46, 47, or 48. The second submission will appear in the Declined Transaction report with a
response Reason Code of 251 - Duplicate Transaction.

2.4.8 Testing Refund Authorization

Beginning in April of 2019, Visa will require the submission of an Authorization for each Credit (Refund)
transaction. When you submit a Credit transaction, Worldpay automatically generates the Authorization
transaction for you. If the Authorization fails, the response message contains a response code normally
used for Authorization declines. The test below illustrates this type of decline.
To test Refund Authorizations, do the following:
1. Submit the Sale transactions for orderId Sale111111 using the data shown in Table 2-10. Verify that
each transactions response indicates approval and that you parse and store the value of the
networkTransactionId element for each transaction.

NOTE: In the Pre-Live environment, the system may return all zeros for the
networkTransactionId.

2. Submit a Credit transaction using the cnpTnxId returned in the Sale response. Verify that you handle
the declined response correctly.

TABLE 2-10 Credit Authorization Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Sale111111 Sale: Authorization

Response:
<amount> 111111
<response> 000
<<type> VI
<message> Approved
<number> 4457002900000009
<expDate> 1223

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

126
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-10 Credit Authorization Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Credit: Credit Response:

<cnpTxnId> Use the value <response> 301
returned from the <message> Invalid Account
above transaction. Number

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

127
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5 Performing the Optional Tests

This section describes data that you can use to test different response codes, messages, and AVS
response codes from the Worldpay, Inc. system for American Express, Visa, Mastercard, Discover, and
Diner’s Club cards. You can perform these tests after completing the certification testing.
This section contains the following topics:
• Testing AVS and Card Validation
• Testing Address Responses
• Testing Advanced AVS Response Codes
• Testing Response Reason Codes and Messages
• Testing 3DS Responses
• Testing the Prepaid Filtering Feature
• Testing the International Card Filter Feature
• Testing Security Code No-Match Filtering
• Testing Advanced Fraud Tools
• Testing Account Updater
• Testing Tax Billing
• Testing Convenience Fees
• Testing the Recycling Engine
• Testing Recurring Engine Transactions
• Testing Gift Card Transactions
• Testing MasterPass Transactions
• Testing Apple Pay Transaction Processing
• Testing Google Pay Transaction Processing
• Testing Amazon Pay
• Testing checkoutId
• Testing Encrypted Card and CVV in Register Token Requests
• Testing Transaction Volume Capacity

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

128
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.1 Testing AVS and Card Validation

Use the AVS tests to test all of the possible AVS response codes that the system can produce, including
those response codes that cannot be produced by varying the address and ZIP code data. For these tests
the AVS response codes are independent of any address or ZIP code data that you submit.
To test AVS response codes:
1. Submit transactions using the card data in Table 2-11. If you are using Card Validation, include the
cardValidationNum element. The Card Validation test will return all possible Card Validation
response codes. The response codes that are returned are independent of the card validation value
that you submit.
2. Verify that the AVS tests return the following response:
<response>000</response>
<message>Approved</message>
<authCode>654321</authCode>
<avsresult>See Table 2-11</avsresult>
<cardValidationResult>See Table 2-11</cardValidationResult>

NOTE: For a list of all possible AVS response codes, see AVS Response Codes on page 859.
For a list of all possible card validation response codes, see Card Validation Response Codes on
page 863.

TABLE 2-11 AVS and Card Validation Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

65 <type> VI <avsResult> 00
<number> 4457000300000007 <cardValidationResult> U

66 <type> VI <avsResult> 01
<number> 4457000100000009 <cardValidationResult> M

67 <type> VI <avsResult> 02
<number> 4457003100000003 <cardValidationResult> M

68 <type> VI <avsResult> 10
<number> 4457000400000006 <cardValidationResult> S

69 <type> VI <avsResult> 11
<number> 4457000200000008 <cardValidationResult> M

70 <type> MC <avsResult> 12
<number> 5112000100000003 <cardValidationResult> M

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

129
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-11 AVS and Card Validation Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

71 <type> MC <avsResult> 13
<number> 5112002100000009 <cardValidationResult> M

72 <type> MC <avsResult> 14
<number> 5112002200000008 <cardValidationResult> N

73 <type> MC <avsResult> 20
<number> 5112000200000002 <cardValidationResult> N

74 <type> MC <avsResult> 30
<number> 5112000300000001 <cardValidationResult> P

75 <type> MC <avsResult> 31
<number> 5112000400000000 <cardValidationResult> U

76 <type> MC <avsResult> 32
<number> 5112010400000009 <cardValidationResult> S

78 <type> MC <avsResult> 34
<number> 5112000600000008 <cardValidationResult> P

80 <type> AX <cardValidationResult> N
<number> 374313304211118 <response> 352
Note: American <message> Decline CVV2/CID
Express CID Fail
failures are declined
by American
Express.

2.5.2 Testing Address Responses

Use the address tests to test different AVS responses by varying the address and ZIP code data. The
address tests are intended to return a realistic AVS response code.
To test address responses:
1. Submit Authorization or Sale transactions in Table 2-12. The AVS tests always return an avsResult
of 00 when submitting 95 Main St. and 95022. If you extend the Zip Code to 9 digits, by appending
1111, the system returns an avsResult of 01, as shown in the second test.
2. The AVS response code depends on the Address Line 1 and ZIP Code that are passed in with the
transaction. Submit additional transactions using the card data from the table, but varying the
address/zip information to receive other avsResult codes in the response messages as shown in
the tests for orderIds AVS3 and AVS4.
For a detailed list of all possible AVS response codes, see AVS Response Codes on page 859.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

130
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-12 AVS and Card Validation Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

AVS1 <type> VI <avsResult> 00

<number> 4457000600000004
<addressLine1> 95 Main St.
<zip> 95022

AVS2 <type> VI <avsResult> 01

<number> 4457000600000004
<addressLine1> 95 Main St.
<zip> 950221111

AVS3 <type> VI <avsResult> 10

<number> 4457000600000004
<addressLine1> 100 Main St.
<zip> 95022

AVS4 <type> VI <avsResult> 20

<number> 4457000600000004
<addressLine1> 100 Main St.
<zip> 02134

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

131
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.3 Testing Advanced AVS Response Codes

The Advanced AVS (AAVS) feature is an offering from American Express that allows you to check several
parameters not normally covered by a standard AVS check, including name, phone, and email.
To test AAVS Response Codes:
1. Submit an Authorization transaction using the data supplied in Table 2-14.
2. Verify that you handle the response correctly.
3. Enter additional transaction varying the values for name, phone, and/or email to trigger other AAVS
results (see AAVS Response Codes on page 860 for other result codes). To obtain a value of 3 in any
position, use one of the following values in the appropriate position:
• <name>Jane Doe</name>
• <phone>5555551234</phone>
• <email>[email protected]</email>
For example, if you submit a second transaction using the name Jane Doe Instead of John Doe, the
AAVS result would be 311 indicating No Match for name, but Match for phone and email.

TABLE 2-13 Advanced AVS Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

81 <amount> 12523 <advancedAVSResults> 111

<name> John Doe
<addressLine1> 95 Main St.
<city> Palo Alto
<state> CA
<zip> 950221111
<country> US
<email> [email protected]
<phone> 6178675309
<type> AX
<number> 341234567890127
<expDate> 1121

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

132
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.4 Testing Response Reason Codes and Messages

Use the data provided in this section to test Response Reason Codes and Messages.

NOTE: f you submit account numbers not specified in the tables, you will receive the following
response:
<response>000</response>
<message>Approved</message>
<authCode>123457</authCode>
<avsResult>00</avsResult>

To test Response Codes and Messages:

1. Submit transactions using the data in Table 2-14. In each case use the supplied card number with a
prefix of RRC- as the orderId.
2. Verify that you handle the response correctly.

NOTE: The messages listed are samples of messages that the system can return. Since the
messages are subject to change at any time, you should use them only for human readability
purposes and not for coding purposes. Always code to the response codes, since these do not
change.

• For a list of all possible response reason codes, see Payment Transaction Response Codes on
page 832.
• For a list of all possible AVS response codes, see AVS Response Codes on page 859.

TABLE 2-14 Response Code Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

<type> VI <response> 000

<number> 4457000800000002 <message> Approved

<type> VI <response> 000

<number> 4457000900000001 <message> Approved
RRC-card #
<type> VI <response> 000
<number> 4457001000000008 <message> Approved

<type> MC <response> 000

<number> 5112000900000005 <message> Approved

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

133
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-14 Response Code Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

<type> AX <response> 120

<number> 375000030000001 <message> Call Issuer

<type> DI <response> 123

<number> 6011000400000000 <message> Cal Discover

<type> VI <response> 120

<number> 4457001200000006 <message> Call Issuer

<type> VI <response> 120

<number> 4457001300000005 <message> Call Issuer

<type> VI <response> 120

<number> 4457001400000004 <message> Call Issuer

<type> MC <response> 101

<number> 5112001000000002 <message> Issuer Unavailable

<type> VI <response> 321

<number> 4457001900000009 <message> Invalid Merchant
RRC-card # <type> VI <response> 303
<number> 4457002000000006 <message> Pick Up Card

<type> VI <response> 110

<number> 4457002100000005 <message> Insufficient Funds

<type> VI <response> 120

<number> 4457002200000004 <message> Call Issuer

<type> AX <response> 350

<number> 375000050000006 <message> Generic Decline

<type> VI <response> 349

<number> 4457002300000003 <message> Do Not Honor

<type> VI <response> 340

<number> 4457002500000001 <message> Invalid Amount

<type> MC <response> 301

<number> 5112001600000006 <message> Invalid Account
Number

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

134
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-14 Response Code Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

<type> MC <response> 301

<number> 5112001700000005 <message> Invalid Account
Number

<type> MC <response> 321

<number> 5112001800000004 <message> Invalid Merchant

<type> VI <response> 101

<number> 4457002700000009 <message> Issuer Unavailable

<type> MC <response> 305

<number> 5112001900000003 <message> Expired Card

<type> VI <response> 322

RRC-card #
<number> 4457002800000008 <message> Invalid Transaction

<type> VI <response> 350

<number> 4457002900000007 <message> Generic Decline

<type> VI <response> 101

<number> 4457003000000004 <message> Issuer Unavailable

<type> MC <response> 101

<number> 5112002000000000 <message> Issuer Unavailable

<type> VI <response> 301

<number> 4457000100000000 <message> Invalid Account
Number

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

135
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.5 Testing 3DS Responses

The cardholder authentication value should only be included by merchants who support 3DS (3 Domain
Secure) electronic commerce transactions. Your systems must be in compliance with the Verified by Visa
or Mastercard Secure Code implementations of 3DS.
To test 3DS responses:
1. Submit Authorization transactions or Sale transactions using the data in Table 2-15. For all tests
except the last three Discover tests, set the orderSource element to either 3dsAuthenticated or
3dsAttempted and the cardholderAuthentication element to the following base64 encoded
string (except as noted for the Discover tests):
BwABBJQ1AgAAAAAgJDUCAAAAAAA=
The response from a 3DS test will be the same as an Authorization or Sale response, except the
response includes the authenticationResult element as a child of the fraudResult element.

TABLE 2-15 3DS Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

3DS1 <type> VI <authenticationResult> 0

<number> 4100200300000004

3DS2 <type> VI <authenticationResult> 1

<number> 4100200300000012

3DS3 <type> VI <authenticationResult> 2

<number> 4100200300000103

3DS4 <type> VI <authenticationResult> A

<number> 4100200300001002

3DS5 <type> VI <authenticationResult> 3

<number> 4100200300000020

3DS6 <type> VI <authenticationResult> 4

<number> 4100200300000038

3DS7 <type> VI <authenticationResult> 5

<number> 4100200300000046

3DS8 <type> VI <authenticationResult> 6

<number> 4100200300000053

3DS9 <type> VI <authenticationResult> 7

<number> 4100200300000061

3DS10 <type> VI <authenticationResult> 8

<number> 4100200300000079

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

136
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-15 3DS Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

3DS11 <type> VI <authenticationResult> 9

<number> 4100200300000087

3DS12 <type> VI <authenticationResult> B

<number> 4100200300000095

3DS13 <type> VI <authenticationResult> C

<number> 4100200300000111

3DS14 <type> VI <authenticationResult> D

<number> 4100200300000129

3DS15 <orderSource> 3dsAttempted <authenticationResult> N/A

<type> MC
<number> 5112010200000001

3DS16 <orderSource> 3dsAttempted <authenticationResult> N/A

<type> MC
<number> 5112010200000001

DI3DS1 <orderSource> 3dsAuthenticated <authenticationResult> 0

<type> DI
<number> 6011000400001008
<cardholderAuth BRICAIASNBERERER
entication> ERERARERERE=

DI3DS2 <orderSource> 3dsAuthenticated <authenticationResult> 1

<type> DI
<number> 6011000400000018
<cardholderAuth FRIBAIASNBERERER
entication> ERERARERERE=

DI3DS3 <orderSource> 3dsAuthenticated <authenticationResult> 2

<type> DI
<number> 6011000400000109
<cardholderAuth JRIBAIASNBERERER
entication> ERERARERERE=

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

137
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.6 Testing the Prepaid Filtering Feature

Complete this test only if you are planning on using the Prepaid Filtering Feature and are using schema
version 8.3 or above.
To test the Prepaid Filtering feature:
1. Submit authorization transactions using the values provided in Supplied Data Elements of Table 2-16.
2. Verify that your response values match those shown in the Key Response Elements section of
Table 2-16.
3. After you complete this test, go to the next test.

TABLE 2-16 Prepaid Filtering Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

filterPrepaidMC <amount> 9100 <response> 309

<orderSource> recurring <message> Restricted Card -
Prepaid Card
<name> John Doe
Filtering Service
<addressLine1> 10 Main St.
<avsResult> 02
<city> San Jose
<state> CA
<zip> 95032
<country> US
<email> jdoe@phoenixProce
ssing.com
<phone> 7812701111
<type> MC
<number> 5500000958501839
<expDate> 1121
<prepaid> true

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

138
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-16 Prepaid Filtering Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

filterPrepaidVI <amount> 9100 <response> 309

<orderSource> recurring <message> Restricted Card -
Prepaid Card
<name> John Doe
Filtering Service
<addressLine1> 10 Main St.
<authCode> none
<city> San Jose
<avsResult> 34
<state> CA
<zip> 95032
<country> US
<email> jdoe@phoenixProce
ssing.com
<phone> 7812701111
<type> VI
<number> 4650002010001478
<expDate> 1121
<prepaid> true

2.5.7 Testing the International Card Filter Feature

Complete this test only if you are planning on using the International Card Filtering Feature and are using
schema version 8.3 or above.
To test the International Card Filtering feature:
1. Submit authorization transactions using the values provided in Supplied Data Elements of Table 2-17.
2. Verify that your response values match those shown in Key Response Elements section of
Table 2-17.
3. After you complete this test, go to the next test.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

139
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-17 International Filtering Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

filterInternational1 <amount> 9100 <response> 312

<orderSource> recurring <message> Restricted Card -
International Card
<name> John Doe
Filtering Service
<addressLine1> 10 Main St.
<avsResult> 34
<city> San Jose
<state> CA
<zip> 95032
<country> US
<email> jdoe@phoenixProce
ssing.com
<phone> 7812701111
<type> VI
<number> 4100200309950001
<expDate> 1121

filterInternational2 <amount> 9100 <response> 000

<orderSource> recurring <message> Approved
<name> John Doe <authCode> 123457
<addressLine1> 10 Main St. <avsResult> 00
<city> San Jose
<state> CA
<zip> 95032
<country> US
<email> jdoe@phoenixProce
ssing.com
<phone> 7812701111
<type> VI
<number> 4100200309950001
<expDate> 1121
<international> false

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

140
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.8 Testing Security Code No-Match Filtering

Complete this test only if you are planning on using the Security Code No-Match Filtering Feature.
To test the Security Code No-Match feature:
1. Submit authorization transactions using the values provided in Supplied Data Elements of Table 2-18.
2. Verify that your response values match those shown in Key Response Elements section of
Table 2-18.
After you complete this test, go to the next test.

TABLE 2-18 Security Code No-Match Filtering Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

securityCodeFilter1 <amount> 9100 <response> 358

<orderSource> ecommerce <message> Restricted by Vantiv
due to security code
<name> John Doe
mismatch.
<addressLine1> 10 Main St.
<avsResult> 14
<city> San Jose
<cardValidationRes N
<state> CA ult>
<zip> 95032
<country> US
<type> MC
<number> 5112002200000008
<expDate> 1121
<cardValidationNum> 123

securityCodeFilter2 <amount> 9100 <response> 358

<orderSource> ecommerce <message> Restricted by Vantiv
due to security code
<name> Jane Doe
mismatch.
<addressLine1> 10 Main St.
<avsResult> 20
<city> San Jose
<cardValidationRes N
<state> CA ult>
<zip> 95032
<country> US
<type> MC
<number> 5112000200000002
<expDate> 1121
<cardValidationNum> 123
<international> false

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

141
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.9 Testing Advanced Fraud Tools

Complete this test only if you are planning on using the Advanced Fraud Tools Feature.
To test the Advanced Fraud Tools feature:
1. Submit authorization transactions using the values provided in Supplied Data Elements of Table 2-19.
For each test, replace "Your Prefix-" with the prefix supplied by your Implementation Consultant.
2. Verify that your response values match those shown in Key Response Elements section of
Table 2-19.

NOTE: You can submit these tests as sale transactions using the supplied data, or as standalone
fraudCheck transactions using just the designated orderId and webSessionId. The results for
each test type will be as shown in the Key response elements section.
Also, please note that the third test, orderId = tmx_fail_order_id, has two possible results
depending upon whether you are configured for Info Only or Auto-Decline.

After you complete this test, go to the next test.

TABLE 2-19 Advanced Fraud Tools Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

tmx_pass_order <amount> 150 <response> 000

_id <type> VI <message> Approved
<number> 4111111111111111 <deviceReviewStatus> pass
<expDate> 1230 <deviceReputationScore> 50
<webSessionId> Your <triggeredRule> FlashDisabled
Prefix-A980A93LP2
O3-KNP0050

tmx_review_ord <amount> 150 Result if Info Only:

er_id
<type> VI <response> 000
<number> 4111111111111111 <message> Approved
<expDate> 1230 <deviceReviewStatus> review
<webSessionId> Your <deviceReputationScore> -20
Prefix-A0S9D8F7G <triggeredRule> PossibleVPNCon
6H5J4-KMR-020 nection
<triggeredRule> PossibleCookieWi
pingWeek

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

142
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-19 Advanced Fraud Tools Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

tmx_fail_order_i <amount> 150 Result if Info Only:

d
<type> VI <response> 000
<number> 4111111111111111 <message> Approved
<expDate> 1230 <deviceReviewStatus> fail
<webSessionId> Your <deviceReputationScore> -100
Prefix-Q1W2E3R4T <<triggeredRule> 5PaymentsOnExa
5Y6U7I8-KHF-100 ctDevice
<triggeredRule> ProxyHasNegativ
eReputation
<triggeredRule>
TrueIPProxyIPCit
yMismatch

Result if Auto-decline:
<response> 550
<message> Restricted Device
or IP -
ThreatMetrix
Fraud Score
Below Threshold
<deviceReviewStatus> fail
<deviceReputationScore> -100
<triggeredRule> 5PaymentsOnExa
ctDevice
<triggeredRule> ProxyHasNegativ
eReputation
<triggeredRule> TrueIPProxyIPCit
yMismatch

tmx_unavail_ord <amount> 150 <response> 000

er_id
<type> VI <message> Approved
<number> 4111111111111111 <deviceReviewStatus> unavailable
<expDate> 1230
<webSessionId> Your
Prefix-Q1W2E3R4T
5Y6U7I8-XLP0050

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

143
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.10 Testing Account Updater

To test Account Updater, you submit a normal Authorization transaction. The certification system returns
an Authorization response that includes Account Update information. You should verify that you correctly
parse the update information.

NOTE: You can also perform the tests in this section using Sale transactions instead of
Authorization transactions.

To test the Account Updater service:

1. Submit authorization transactions using the values provided in Supplied Data Elements of Table 2-20.
2. Verify that your response values match those shown in Key Response Elements section of
Table 2-20.
3. If you have coded to receive Extended Response Codes, proceed to the next test.

TABLE 2-20 Account Updater Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

100 <amount> 10000 <originalCardInfo> (parent element)

<type> VI <type> VI
<number> 4457000300000007 <number> 4457000300000007
<expDate> 0115 <expDate> 0115
<newCardInfo> (parent element)
<type> MC
<number> 5112000100000003
<expDate> 0115
<extentedCardResponse> (parent element)
<code> 500
<message> The account number
was changed

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

144
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-20 Account Updater Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

101 <amount> 10000 <originalCardInfo> (parent element)

<type> DI <type> DI
<number> 6500102087026221 <number> 6500102087026221
<expDate> 0115 <expDate> 0115
<newCardInfo> (parent element)
<type> DI
<number> 6011102077026225
<expDate> 0115
<extentedCardResponse> (parent element)
<code> 500
<message> The account number
was changed

2.5.10.1 Testing Account Updater Extended Response Codes

To test the Account Updater Extended Response Codes feature:

1. Submit authorization transactions using the values provided in Supplied Data Elements of
Table 2-21.
2. Verify that the response values match those shown in Key Response Elements section of Table 2-21
and that your systems parse the data correctly. The second test case does not include account repair
information only the Extended Response Code.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

145
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-21 Account Updater Extended Response Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

102 <amount> 10000 <originalCardInfo> (parent element)

<type> MC <type> MC
<number> 5112000101110009 <number> 5112000101110009
<expDate> 1199 <expDate> 1199
<newCardInfo> (parent element)
<type> VI
<number> 4457000302200001
<expDate> 1199
<extendedCardResponse> (parent element)
<code> 501
<message> The account was
closed.

103 <amount> 10000 <extendedCardResponse> (parent element)

<type> VI <code> 504
<number> 4457000301100004 <message> Contact the
cardholder for
<expDate> 1199
updated information.

2.5.10.2 Testing Account Updater for Tokenized Merchants

If you are a tokenized merchant using the Account Updater service, you can test this service using the
card information provided in Table 2-20. In this case you will receive an original and new token in the
<accountUpdater> section of the Authorization response message (see accountUpdater Structure -
Credit Cards (tokenized Merchant) on page 335).

2.5.11 Testing Tax Billing

This test applies only to merchants with MCC 9311.
To test Tax Billing and Convenience Fee transactions:
1. Submit authorization transactions using the values provided in Supplied Data Elements of
Table 2-22. Note: The second transactions omits the <taxType> element.
2. Verify that the system returns a response code of 000 - Approved for the first transaction and
response code of 851 - MCC 9311 requires taxType element for the second.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

146
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-22 Tax Billing Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

MCC9311Test <amount> 3000 <response> 000

<type> VI <message> Approved
<number> 4457010200000247
<expDate> 1121
<taxType> fee

MCC9311Test2 <amount> 3000 <response> 851

<type> VI <message> MCC 9311
requires taxType
<number> 4457010200000247
element
<expDate> 1121

2.5.12 Testing Convenience Fees

You include Convenience Fees through the use of the secondaryAmount element.
To test the use of Convenience Fees submit the transactions detailed below:
1. Submit authorization or sale transactions for the first five transactions of Table 2-23 using the
values provided in Supplied Data Elements columns.
2. Verify that the response values match those shown in Key Response Elements section of Table 2-23
for those transactions and that your systems parse the data correctly.
3. Submit sale transactions for Order Id SaleWOSecondary using the data provided.
4. After receiving an approval for the sale transaction, submit a credit transaction using the cnpTxnId
from the sale transaction and including the secondaryAmount element with the value provided.
5. Verify that the response values match those shown in Key Response Elements section for the credit
transaction using Order Id SaleWOSecondary and that your systems parse the data correctly.

TABLE 2-23 Convenience Fee Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

Visa_secondary <amount> 10500 <response> 000

Amount
<type> VI <message> Approved
<number> 4457010200000247
<expDate> 1121
<secondaryAmount> 10000

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

147
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-23 Convenience Fee Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

SecondaryAmt_ <amount> 2500 <response> 380

Higher
<type> VI <message> Secondary Amount
cannot exceed the
<number> 4111111111111111
sale amount
<expDate> 1230
<secondaryAmount> 3000

MOP_Unsuppor <amount> 6002 <response> 381

ted
<type> AX <message> This method of
payment does not
<number> 375001010000003
support secondary
<expDate> 0421 amount
<secondaryAmount> 1100

Negative_Secon <amount> 1000 <response> 382

dary
<type> VI <message> Secondary Amount
cannot be less
<number> 4457010200000247
than zero
<expDate> 1121
<secondaryAmount> -500

Partial_Not_Allo <amount> 2500 <response> 383

wed
<type> VI <message> Partial transaction
is not supported
<number> 4111111111111111
when including a
<expDate> 1230 secondary amount
<secondaryAmount> 3000
<allowPartialAuth> true

SaleWOSecond <amount> 1000 <response> 000

ary
<type> MC <message> Approved
(Sale TXN)
<number> 5112010140000004
<expDate> 1121

SaleWOSecond <cnpTxnId> Value from previous <response> 000

ary transaction <message> Approved
(Credit Txn) <amount> 1000
<secondaryAmount> 400
Declined
Transaction report
result = 385 -
Secondary amount
not allowed on
refund if not
included on deposit

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

148
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.13 Testing the Recycling Engine

The Certification test cases for the Recycling Engine serve two purposes. First, you use the test
transactions to verify your handling of the responses you receive if you submit additional Authorization
transactions for a declined auth being handled by the engine. Second, you can verify your process for
retrieving and processing recycling completion files via sFTP.
There are three test scenarios you can use to test the Recycling Engine and your ability to parse the
response messages and/or result Batches. The particular data sets and scenarios you use depends upon
the version of cnpAPI you use, as well as your plans for retrieving the response messages. Use the
following to determine which tests you should run:
• If you plan to retrieve recycling results via the results Batches posted daily to the FTP site, perform
the tests in Scenario 1.
• If you are using cnpAPI schema version V8.6 or above, perform the tests in Scenario 2.

Scenario 1
To test your handling of the Recycling Results Session file:
1. Submit authorization (or sale) transactions using the values provided in the Supplied Data
Elements column of Table 2-24. Please use the same value for the orderId and if applicable, the
recycleId elements.

NOTE: If your configuration is set for Worldpay to recycle by default, you can omit the <recycleBy>
element.

2. Wait a minimum of 2 hours after submitting the last transaction. After 2 hours, retrieve the Results
Session file from the FTP site.

TABLE 2-24 Recycling Engine Test Data - Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 10000 Initial Response:

r1
<type> VI <response> 110
<number> 4457012400000027 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 000
<message> Approved

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

149
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-24 Recycling Engine Test Data - Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 10000 Initial Response:

r2
<type> MC <response> 110
<number> 5160124000000029 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 000
<message> Approved

XXXCase1Orde <amount> 10000 Initial Response:

r3
<type> VI <response> 110
<number> 4100200700000059 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 110
<message> Insufficient Funds

XXXCase1Orde <amount> 10000 Initial Response:

r4 <type> MC <response> 110
<number> 5500010000000052 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 110
<message> Insufficient Funds

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

150
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-24 Recycling Engine Test Data - Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 10000 Initial Response:

r5
<type> VI <response> 110
<number> 4457032800000047 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 328
<message> Cardholder
requests that
recurring or
installment
payment be
stopped

XXXCase1Orde <amount> 10000 Initial Response:

r6
<type> MC <response> 110
<number> 5160328000000042 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Final Response
(in FTP Session
File):
<response> 120
<message> Call Issuer

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

151
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-24 Recycling Engine Test Data - Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 10000 Initial Response:

r7
<type> VI <response> 302
<number> 5160328000000042 <message> Account Number
Does Not Match
<expDate> 1220
Payment Type
<recycleBy> Cnp
<recyclingEngineA false
ctive>
Final Response
(in FTP Session
File):
None - This type of
decline is not
recycled.

Scenario 2
To test your handling of the Intercept Response Codes/Messages, as well as the Recycling Results
Session file and Normal Batch/Online responses:
1. Submit authorization (or sale) transactions using the values provided in the Supplied Data
Elements column of Table 2-25. Please use the same value for the orderId and if applicable, the
recycleId elements.

NOTE: If your configuration is set for Worldpay to recycle by default, you can omit the <recycleBy>
element.

2. If you are using schema version V8.6 or above, resubmit any of the first four transactions within 36
hours to receive a response message containing the intercept Response Reason Code 372 - Soft
Decline - Auto Recycling In Progress. If you are using schema version 8.5 or below, you will receive a
response message with the same Response Reason Code as in the initial response message.
3. Wait a minimum of 36 hours after submitting the last of the initial transactions. After 36 hours, you can
retrieve the Results Session file from the FTP site and/or resubmit the transaction. The responses will
contain the data shown for the Final Response.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

152
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-25 Recycling Engine Test Data - Intercept and Online or Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase3Orde <amount> 20000 Initial Response:

r1
<type> DI <response> 350
<number> 6223012400000025 <message> Generic Decline
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Intermediate
Attempts (V8.6):
<response> 372
<message> Soft decline -
Recycling In
Progress
<recyclingEngineA true
ctive>
Final Response
(Online/Normal
Batch, or in FTP
Session File):
<response> 000
<message> Approved

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

153
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-25 Recycling Engine Test Data - Intercept and Online or Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase3Orde <amount> 20000 Initial Response:

r2
<type> AX <response> 350
<number> 377201240000025 <message> Generic Decline
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Intermediate
Attempts (V8.6):
<response> 372
<message> Soft decline -
Recycling In
Progress
<recyclingEngineA true
ctive>
Final Response
(Online/Normal
Batch, or in FTP
Session File):
<response> 000
<message> Approved

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

154
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-25 Recycling Engine Test Data - Intercept and Online or Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase3Orde <amount> 20000 Initial Response:

r3
<type> DI <response> 350
<number> 6223012400000033 <message> Generic Decline
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Intermediate
Attempts (V8.6):
<response> 372
<message> Soft decline -
Recycling In
Progress
<recyclingEngineA true
ctive>
Final Response
(Online/Normal
Batch, or in FTP
Session File):
<response> 373
<message> Hard Decline -
Auto Recycling
Complete

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

155
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-25 Recycling Engine Test Data - Intercept and Online or Results Session File Pick-up

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase3Orde <amount> 20000 Initial Response:

r4
<type> DI <response> 101
<number> 6011002078551608 <message> Issuer Unavailable
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp
Intermediate
Attempts (V8.6):
<response> 372
<message> Soft decline -
Recycling In
Progress
<recyclingEngineA true
ctive>
Final Response
(Online/Normal
Batch, or in FTP
Session File):
<response> 373
<message> Hard Decline -
Auto Recycling
Complete

XXXCase3Orde <amount> 20000 Initial Response:

r5
<type> VI <response> 302
<number> 377203280000048 <message> Account Number
Does Not Match
<expDate> 1220
Payment Type
<recycleBy> Cnp
<recyclingEngineA false
ctive>
All Responses:
None - This type of
decline is not
recycled.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

156
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.13.1 Testing Recycling Engine Cancellation

You use an authReversal transaction to halt the automatic recycling of an authorization. For a sale
transaction, use a void transaction to halt recycling.

NOTE: You can perform this test either after completing the Recycling Engine test or prior to
starting that test.

To test recycling cancellation:

1. Submit a sale transaction using the values provided for Case1Order1a and an authorization
transaction using the values provided for Case1Order2a in the Supplied Data Elements of Table 2-26.
2. Two (2) hours after receiving the decline message, submit a void transaction using the cnpTxnId
returned in the response message for Case1Order1a. If you are not enabled for Auto-refunding an
approved Sales on Void, the Declined transaction report will contain a response code of 362 -
Transaction not Voided - Already Settled.

NOTE: If you submit the Void transaction (Step 2) within 2 hours of the initial transaction
submission, you will receive a voidResponse with a response code of 000 - Approved.

3. After receiving the decline messages, submit an authReversal transaction using the cnpTxnId
returned in the response message for Case1Order2a. This will halt the recycling of the order.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

157
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-26 Recycling Engine Cancellation Test Data

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 11000 Initial Response:

r1a
<type> VI <response> 110
<number> 4457012400000027 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp

Submit Void using Void Response (if

cnpTxnId from enabled for
Initial Response Auto-Refund):
<response> 000
<message> Approved
<creditcnpTxnId> (Random Value)

Void Response (if

not enabled for
Auto-Refund:
000
<response> Approved
<message>

Declined
Transaction report
result = 362 -
Transaction Not
Voided - Already
Settled

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

158
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-26 Recycling Engine Cancellation Test Data

orderId or Supplied Data Elements Key Response Elements

recycleId
(replace XXX
with your
merchantId) Element Value Element Value

XXXCase1Orde <amount> 11000 Initial Response:

r2a
<type> MC <response> 110
<number> 5160124000000029 <message> Insufficient Funds
<expDate> 1220 <recyclingEngineA true
ctive>
<recycleBy> Cnp

authReversalResp
Submit
onse:
authReversal
using cnpTxnId <response> 000
from Initial <message> Approved
Response

2.5.14 Testing Recurring Engine Transactions

Use the following Certification tests to verify transactions associated with the Recurring Engine
functionality. For testing purposes, the Certification environment will process the first recurring transaction
within 2 hours. The system cancels subsequent recurring transactions in the payment stream. For
example, if you submitted an Authorization at 9:00 AM that set-up a subscription for twelve monthly
payments, the Cert Recurring Engine would process the first payment by 11:00 AM and cancel the
remaining eleven payments.

IMPORTANT: The test data supplied does not necessarily account for all data fields/XML elements
in a particular request. Where test data is not supplied, you should provide appropriate information.
You should never override your own system to enter supplied data. If you are unable to enter the
supplied data without overriding your system, please consult your Implementation Consultant
concerning the test and how to proceed.

To test the Recurring Engine functionality using the data supplied in Table 2-27:
1. Submit createPlan transactions for Order Ids R1.1, R1.2, R1.3, R1.4, R1.5, and R1.6. These
transactions establish Plans used in the remaining tests, as well as verify your cnpAPI messages
used to create Plans. You can use whatever values you wish for the <planCode> and <name>
elements. Verify that each transaction receives an approval code in the response message.
2. Submit createPlan transactions for Order Id R1.7 using the same <planCode> value you used in
R1.3. This transaction is declined, because the Plan Code already exists. Verify that the transaction
receives a response code of 487 - Plan code already exists.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

159
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

3. Submit a sale transaction for Order Id R2.1. This transaction creates a subscription using the plan
established in Order R1.1. The amount in the sale transaction represents a set-up fee and not the
initial payment. Verify that the transaction receives an approval code in the response message.
4. Submit an authorization transaction for Order Id R2.2. This transaction creates a subscription
using the plan established in Order R1.1. Because the Authorization did not specify a start date, the
Recurring Engine schedules the first payment for the current date. Verify that the transaction receives
an approval code in the response message.

NOTE: The transaction specified in Order 2.2 is a $0 Auth. If you include an amount when using an
Auth to establish a subscription, you should plan on reversing the Auth to avoid a Misuse of Auth
fee. The Recurring Engine obtains its own Auth for the first payment.

5. Submit an updateSubscription transaction for Order Id R2.3. This transaction updates the
subscription initiated with Order Id 2.1, changing the Plan to the plan you created in R1.2.
6. Submit a sale transaction for Order Id R3.1. This transaction utilizes a Sale transaction to initialize a
subscription based upon the plan created in R1.3, but overrides both the number of payments and the
amount specified in the Plan. Verify that the transaction receives an approval code in the response
message.
7. Submit an authorization transaction for Order Id R3.2. This transaction utilizes an Authorization
transaction to initialize a subscription based upon the plan created in R1.3, but overrides both the
number of payments and the amount specified in the Plan. Verify that the transaction receives an
approval code in the response message.
8. Submit an updateSubscription transaction for Order Id R3.3. This transaction updates an
existing subscription, changing the billing date.
9. Submit an authorization transaction for Order Id R4.1. This transaction utilizes an Authorization
transaction to initialize a subscription that overrides the default amount in the Plan and has a trial
period. Verify that the transaction receives an approval code in the response message.
10. Submit an updateSubscription transaction for Order Id R4.2. This transaction updates an
existing subscription with a new credit card number.
11. Submit an authorization transaction for Order Id R5.1. This transaction utilizes an Authorization
transaction to initialize a subscription based upon the SEMIANNUAL_PLAN, but overrides the
number of payments. Verify that the transaction receives an approval code in the response message.
12. Submit an updateSubscription transaction for Order Id R5.2. This transaction updates an
existing subscription with new billing information.
13. Submit an updateSubscription transaction for Order Id R5.3. Since the transaction does not
include any updated information, the Declined Transaction report will contain a response code of 484
- Insufficient data to update subscription. Verify the response code by accessing the Declined
Transaction report in Worldpay eComm iQ.
14. Submit an updateSubscription transaction for Order Id R5.4. Since the transaction specifies a
new billing date in the past, the Declined Transaction report will contain a response code of 485 -
Invalid billing date. Verify the response code by accessing the Declined Transaction report in
Worldpay eComm iQ.
15. Submit an authorization transaction for Order Id R6.1. The system declines this transaction,
since it uses an invalid Plan Code. Verify that the transaction receives a response code of 472 -
Invalid plan code.
16. Submit an updateSubscription transaction for Order Id R6.2. Since this order uses an invalid
subscription Id, The system declines this transaction, the Declined Transaction report will contain a

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

160
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

response code of 482 - Invalid start date. Verify the response code by accessing the Declined
Transaction report in Worldpay eComm iQ.
17. Submit an authorization transaction for Order Id R6.3. The system declines this transaction,
since it uses a start date in the past. Verify that the transaction receives a response code of 475 -
Invalid Subscription Id.
18. Submit an authorization transaction for Order Id R7.1. This transaction utilizes an Authorization
transaction to initialize a subscription based upon the PLAN_WITH_PROMOTIONS Plan with an add
On and a Discount applied. Verify that the transaction receives an approval code in the response
message.
19. Submit an updateSubscription transaction for Order Id R7.2. This transaction attempts to update
an existing subscription with a new Add On, but is declined because the Add On already exists. Verify
that the Declined Transaction report contains a response code of 476 - Add On already exists.
20. Submit an updateSubscription transaction for Order Id R7.3. This transaction attempts to update
an Add On for an existing subscription, but is declined because the specified Add On is not
associated with the Subscription. Verify that the Declined Transaction report contains a response
code of 478 - No matching Add On code for the subscription.
21. Submit an updateSubscription transaction for Order Id R7.4. This transaction attempts to update
an Add On for an existing subscription, but is declined because the specified Add On is not
associated with the Subscription. Verify that the Declined Transaction report contains a response
code of 478 - No matching Add On code for the subscription.
22. Submit an updateSubscription transaction for Order Id R7.5. This transaction attempts to update
a Discount for an existing subscription, but is declined because the specified Discount is not
associated with the Subscription. Verify that the Declined Transaction report contains a response
code of 480 - No matching Discount code for the subscription.
23. Submit an authorization transaction for Order Id R8.1. This transaction utilizes an Authorization
transaction to initialize a subscription, but includes duplicate Add Ons. Verify that the transaction
receives a response code of 477 - Duplicate add-on codes in request.
24. Submit an authorization transaction for Order Id R8.2. This transaction utilizes an Authorization
transaction to initialize a subscription, but includes duplicate Discounts. Verify that the transaction
receives a response code of 481 - Duplicate discount codes in request.
25. Submit an authorization transaction for Order Id R9.1. In this case the parent Authorization
transaction is declined with a response code of 301 - Invalid Account Number. The response code
associated with the recurring request is 471 - Parent transaction declined - Recurring subscription not
created.PREMIUM_MONTHLY
26. Submit an cancelSubscription transaction for Order Id R10.1. Verify that the transaction receives
an approval code in the response message.
27. Submit an updatePlan transaction for Order Id R11.1. This transaction changes the Plan to an
inactive state. Verify that the transaction receives an approval code in the response message.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

161
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R1.1 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> Basic monthly plan
<intervalType> MONTHLY
<amount> 5000
<numberOfPayments> 12

R1.2 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> Premium monthly
plan
<intervalType> MONTHLY
<amount> 7000
<numberOfPayments> 12

R1.3 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> An annual plan
<intervalType> ANNUAL
<amount> 14000

R1.4 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> A monthly plan with
trial period
<intervalType> MONTHLY
<amount> 5000
<trialIntervalType> MONTH
<trialNumberOfIntervals> 2

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

162
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R1.5 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> A semi-annual plan
<intervalType> SEMIANNUAL
<amount> 7000

R1.6 <createPlan> (parent element) <response> 000

<planCode> Your Value <message> Approved
<name> Your Value <planCode> Your Value
<description> A plan with Add Ons
and Discounts
<intervalType> MONTHLY
<amount> 5000

R1.7 <createPlan> (parent element) <response> 487

<planCode> Value from R1.3 <message> Plan code already
exists
<name> Value from R1.3
<planCode> Value from R1.3
<description> An annual plan
<intervalType> ANNUAL
<amount> 5000

R2.1 <sale> (parent element) <recurringResponse> (parent element)

<amount> 1000 <responseCode> 470
<recurringRequest> (parent element) <responseMessage> Approved - Recurring
subscription created
<subscription> (parent element)
<planCode> Value from R1.1
<startDate> Use any date

R2.2 <authorization> (parent element) <recurringResponse> (parent element)

<amount> 000 <responseCode> 470
<recurringRequest> (parent element) <responseMessage> Approved - Recurring
subscription created
<subscription> (parent element)
<planCode> Value from R1.1

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

163
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R2.3 <updateSubscription> (parent element) <subscriptionId> (parent element)

<subscriptionId> Value returned in <response> 000
R2.1 response <message> Approved
<planCode> Value from R1.2

R3.1 <sale> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 470
<subscription> (parent element) <responseMessage> Approved - Recurring
subscription created
<planCode> Value from R1.3
<startDate> Use any valid date in
the future.

<numberOfPayments> 6
<amount> 4000

R3.2 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 470
<subscription> (parent element) <responseMessage> Approved - Recurring
subscription created
<planCode> Value from R1.3
<startDate> Use any valid date in
the future.

<numberOfPayments> 6
<amount> 4000

R3.3 <updateSubscription> (parent element) <response> 000

<subscriptionId> Value returned in <message> Approved
R3.1 response

<billingDate> Use any valid date in

the future and
different from date
used in R3.1.

R4.1 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 470
<subscription> (parent element) <responseMessage> Approved - Recurring
<planCode> Value from R1.4 subscription created

<startDate> Use any valid date in

the future.
<amount> 4000

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

164
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R4.2 <updateSubscription> (parent element) <response> 000

<subscriptionId> Value returned in <message> Approved
R4.1 response

<card> (parent element)

<type> VI
<number> 4457010000000009
<expDate> 1221

R5.1 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 470
<subscription> (parent element) <responseMessage> Approved - Recurring
subscription created
<planCode> Value from R1.5
Use any valid date in
<startDate> the future.

6
<numberOfPayments>

R5.2 <updateSubscription> (parent element) <subscriptionId> Value returned in

R5.1 response
<subscriptionId> Value returned in
R5.1 response <response> 000
<message> Approved
<billToAddress> (parent element)
<name> John
<addressLine1> 900 Chelmsford St.
<city> Lowell
<state> MA
<zip> 01781
<country> US
<email> [email protected]
<phone> 8559658965

R5.3 <updateSubscription> (parent element) <response> 000

<subscriptionId> Value returned in <message> Approved
R5.1 response

Declined Transaction
report result = 484 -
Insufficient data to
update subscription

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

165
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R5.4 <updateSubscription> (parent element) <response> 000

<subscriptionId> Value returned in <message> Approved
R5.1 response

<billingDate> 2000-10-01 Declined Transaction

report result = 485 -
Invalid billing date

R6.1 <authorization> (parent element) <responseCode> 472

<recurringRequest> (parent element) <responseMessage> Invalid plan code
<subscription> (parent element)
<planCode> INVALID_PLAN

R6.2 <updateSubscription> (parent element) <response> 000

<subscriptionId> 1111111111 <message> Approved
<billToAddress> (parent element)
<name> John Declined Transaction
report result = 475 -
<addressLine1> 900 Chelmsford St.
Invalid Subscription Id
<city> Lowell
<state> MA
<zip> 01781
<country> US
<email> [email protected]
<phone> 8559658965

R6.3 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 482
<subscription> (parent element) <responseMessage> Invalid start date
<planCode> Value from R1.1
<startDate> 2000-04-04

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

166
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R7.1 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 470
<subscription> (parent element) <responseMessage> Approved - Recurring
Subscription Created
<planCode> Value from R1.6
(parent element)
<createAddOn> SSL_ADDON
<addOnCode> Additional Service
<name> 1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate> (parent element)
<createDiscount> PROMO_DISCOUN
<discountCode> T
Special Offer
<name>
1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate>

R7.2 <updateSubscription> (parent element) <recurringResponse> (parent element)

<subscriptionId> Value returned in <response> 000
R7.1 response <message> Approved
<createAddOn> (parent element)
<addOnCode> SSL_ADDON Declined Transaction
<name> Additional Service report result = 476 -
Add-on code already
<amount> 1000
exists
<startDate> 2013-08-30
<endDate> 2050-08-30

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

167
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R7.3 <updateSubscription> (parent element) <response> 000

<subscriptionId> Value returned in <message> Approved
R7.1 response
<createDiscount> (parent element) Declined Transaction
<discountCode> PROMO_DISCOUN report result = 486 -
T Discount code already
<name> Special Offer exists

<amount> 1000
<startDate> 2013-08-30
<endDate> 2050-08-30

R7.4 <updateSubscription> (parent element) <response> 478

<subscriptionId> Value returned in <message> No matching Add-on
R7.1 response code for the
subscription
<updateAddOn> (parent element) Declined Transaction
<addOnCode> INVALID_ADDON_C report result = 478 -
ODE No matching Add-on
<name> Extra Features code for the
subscription
<amount> 1000

R7.5 <updateSubscription> (parent element) <response> 480

<subscriptionId> Value returned in <message> No matching
R7.1 response Discount code for the
subscription
<updateDiscount> (parent element) Declined Transaction
<discountCode> INVALID_DISCOUN report result = 480 -
T_CODE No matching Discount
<name> Special Offer code for the
subscription
<amount> 1000
<startDate> 2013-08-30
<endDate> 2050-08-30

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

168
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R8.1 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <response> 477
<subscription> (parent element) <message> Duplicate Add-on
codes in request
<planCode> Value from R1.6
(parent element)
<createAddOn> SSL_ADDON
<addOnCode> Additional Service
<name> 1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate> (parent element)
<createAddOn> SSL_ADDON
<addOnCode> Additional Service
<name> 1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

169
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-27 Recurring Engine Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

R8.2 <authorization> (parent element) <recurringResponse> (parent element)

<recurringRequest> (parent element) <responseCode> 481
<subscription> (parent element) <responseMessage> Duplicate discount
codes in request
<planCode> Value from R1.6
(parent element)
<createDiscount> PROMO_DISCOUN
<discountCode> T
Discount
<name>
1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate>
(parent element)
<createDiscount> PROMO_DISCOUN
<discountCode> T
Discount
<name>
1000
<amount> 2013-08-30
<startDate> 2050-08-30
<endDate>

R9.1 <authorization> (parent element) <recurringResponse> (parent element)

<card> (parent element) <responseCode> 471
<type> MC <responseMessage> Parent transaction
declined - Recurring
<number> 5112010100000002
subscription not
<expDate> 0721 created
<recurringRequest> (parent element)
<subscription> (parent element)
<planCode> Value from R1.6

R10.1 <cancelSubscription> (parent element) <recurringResponse> (parent element)

<subscriptionId> Value returned in <subscriptionId> Submitted value
R7.1 response
<response> 000
<message> Approved

R11.1 <updatePlan> (parent element) <response> 000

<planCode> Value from R1.2 <message> Approved
<active> false

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

170
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.15 Testing Gift Card Transactions

Use the following Certification tests to verify transactions associated with the Private Label Gift Card
functionality. The tests are designed so that you can verify your XML structure for each transaction type,
as well as your ability to parse the response data.
To test the Gift Card functionality using the data supplied in Table 2-28:

NOTE: When processing gift cards, many transactions response messages include the refCode,
sequenceNumber, systemTraceId, and txnTime elements. You should always store these
values for possible use in subsequent transactions. For example, to perform the
giftCardCapture in test GC2A, you must include the values returned for these elements in the
associated authorization transaction, GC2.

1. Submit an activate transaction for Order Id GC1. Verify that the data in the response message
matches the Key Response Elements specified in the table.
2. Submit an activate transaction for Order Id GC1A. This transaction activates a Virtual Gift Card.
Verify that the data in the response message matches the Key Response Elements specified in the
table.
3. Submit an authorization transaction for Order Id GC2. Verify that the data in the response
message matches the Key Response Elements specified in the table.
4. Submit a giftCardCapture transaction for Order Id GC2A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
5. Submit a giftCardCredit transaction for Order Id GC2B. Verify that the data in the response
message matches the Key Response Elements specified in the table.
6. Submit a deactivate transaction for Order Id GC3. Verify that the data in the response message
matches the Key Response Elements specified in the table.
7. Submit a load transaction for Order Id GC4. Verify that the data in the response message matches
the Key Response Elements specified in the table.
8. Submit a unload transaction for Order Id GC5. Verify that the data in the response message
matches the Key Response Elements specified in the table.
9. Submit a balanceInquiry transaction for Order Id GC6. Verify that the data in the response
message matches the Key Response Elements specified in the table.
10. Submit an activate transaction for Order Id GC7. Verify that the data in the response message
matches the Key Response Elements specified in the table.
11. Submit an activateReversal transaction for Order Id GC7A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
12. Submit an activateReversal transaction for Order Id GC1A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
13. Submit an authorization transaction for Order Id GC8. Verify that the data in the response
message matches the Key Response Elements specified in the table.
14. Submit an authorizationReversal transaction for Order Id GC8A. Verify that the data in the
response message matches the Key Response Elements specified in the table.
15. Submit a sale transaction for Order Id GC9. Verify that the data in the response message matches
the Key Response Elements specified in the table.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

171
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

16. Submit a depositReversal transaction for Order Id GC9A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
17. Submit a sale transaction for Order Id GC10. Verify that the data in the response message matches
the Key Response Elements specified in the table.
18. Submit a giftCardCredit transaction for Order Id GC10A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
19. Submit a refundReversal transaction for Order Id GC10B. Verify that the data in the response
message matches the Key Response Elements specified in the table.
20. Submit a deactivate transaction for Order Id GC11. Verify that the data in the response message
matches the Key Response Elements specified in the table.
21. Submit a loadReversal transaction for Order Id GC12. Verify that the data in the response
message matches the Key Response Elements specified in the table.
22. Submit an unload transaction for Order Id GC13. Verify that the data in the response message
matches the Key Response Elements specified in the table.
23. Submit an unloadReversal transaction for Order Id GC13A. Verify that the data in the response
message matches the Key Response Elements specified in the table.
24. Submit an activate transaction for Order Id GC14. This transaction is declined with a response
code of 301 - Invalid Account Number. Verify that the data in the response message matches the Key
Response Elements specified in the table.
25. Submit an activate transaction for Order Id GC15. This transaction is declined with a response
code of 217 - Already active, because it attempts to activate the same card already activated in Order
Id GC1. Verify that the data in the response message matches the Key Response Elements specified
in the table.
26. Submit an authorization transaction for Order Id GC16. This transaction is declined with a
response code of 110 - Insufficient Funds. Verify that the data in the response message matches the
Key Response Elements specified in the table.
27. Submit an authorization transaction for Order Id GC17. This transaction is declined with a
response code of 281 - Card not active. Verify that the data in the response message matches the
Key Response Elements specified in the table.
28. Submit a sale transaction for Order Id GC19. Verify that the data in the response message matches
the Key Response Elements specified in the table.
29. Submit a giftCardCredit transaction for Order Id GC19A. For this transaction the Declined
Transaction report will contain response code of 304 - Lost/Stolen Card.
30. Submit a balanceInquiry transaction for Order Id GC20. This transaction is declined with a
response code of 352 - Invalid CVV2. Verify that the data in the response message matches the Key
Response Elements specified in the table.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

172
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC1 Activate: Activate Response:

<amount> 15000 <response> 000
<type> GC <message> Approved
<number> Supplied by <cardValidationResu M
Implementation lt>
Consultant
<availableBalance> 15000
<expDate> 1220
<cardValidationNum> 123

GC1A Virtual Activate: Activate Response:

<amount> 8000 <response> 000
<accountNumberLength 16 <message> Approved
> <availableBalance> 8000
<giftCardBin> Supplied by
<accountNumber> 603571xxxxxxxx
Implementation
xx
Consultant

GC2 Authorization: Authorization

Response:
<amount> 1500
<type> GC <response> 000
<number> Number from GC1 <message> Approved
<expDate> 1220 <authCode> 11111
<cardValidationNum> 123 <cardValidationResu M
lt>
<availableBalance> 13500

GC2A Gift Card Capture: Capture Response:

<cnpTxnId> Value from GC2 resp. <response> 000
<captureAmount> 1500 <message> Approved
<type> GC
<number> Number from GC2
<expDate> 1220
<cardValidationNum> 123
<originalRefCode> refCode from GC2
<originalAmount> amount from GC2
<originalTxnTime> txnTime from GC2

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

173
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC2B Gift Card Credit: Credit Response:

<cnpTxnId> Value from GC2A resp. <response> 000
<creditAmount> 500 <message> Approved
<type> GC
<number> Number from GC2
<expDate> 1220

CG3 Deactivate: Deactivate

Response:
<type> GC
<number> Supplied by <response> 000
Implementation <message> Approved
Consultant
<availableBalance> 0

GC4 Load: Load Response:

<amount> 5000 <response> 000
<type> GC <message> Approved
<number> Supplied by <cardValidationResu M
Implementation lt>
Consultant <availableBalance> 5000
<expDate> 0121
<cardValidationNum> 123

GC5 Unload: Unload Response:

<amount> 2500 <response> 000
<type> GC <message> Approved
<number> Number from GC4 <cardValidationResu M
lt>
<expDate> 0121
<availableBalance> 2500
<cardValidationNum> 123

GC6 Balance Inquiry: Balance Inquiry

Response:
<type> GC
<number> Number from GC1 <response> 000
<expDate> 0121 <message> Approved
<cardValidationNum> 123 <cardValidationResu M
lt>
<availableBalance> 2500

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

174
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC7 Activate: Activate Response:

<amount> 8000 <response> 000
<type> GC <message> Approved
<number> Supplied by <cardValidationResu M
Implementation lt>
Consultant
<availableBalance> 8000
<expDate> 1215
<cardValidationNum> 123

GC7A Activate Reversal: Activate Reversal

Response:
<cnpTxnId> Value from GC7 resp.
<type> from GC7 <response> 000
<number> from GC7 <message> Approved
<expDate> from GC7
<originalRefCode> refCode from GC7
<originalAmount> amount from GC7
<originalSystemTraceId> systemTraceId from GC7
<originalSequenceNumb sequenceNumber from
er> GC7

GC7B Activate Reversal: Activate Reversal

Response:
<cnpTxnId> Value from GC1A resp.
<type> from GC1 <response> 000
<number> from GC1 <message> Approved
<expDate> from GC1
<originalRefCode> refCode from GC1A
<originalAmount> amount from GC1A
<originalSystemTraceId> systemTraceId from
GC1A
<originalSequenceNumb sequenceNumber from
er> GC1A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

175
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC8 Authorization: Authorization

Response:
<amount> 2000
<type> GC <response> 000
<number> Supplied by <message> Approved
Implementation
<authCode> 11111
Consultant
<cardValidationResu M
<expDate> 1220 lt>
<cardValidationNum> 123 <availableBalance> 4000

GC8A Gift Card Auth Auth Reversal

Reversal: Response:
<cnpTxnId> Value from GC8 resp. <response> 000
<type> from GC8
<message> Approved
<number> from GC8
<expDate> from GC8
<originalRefCode> refCode from GC8
<originalAmount> amount from GC8
<originalSystemTraceId> systemTraceId from GC8
<originalSequenceNumb sequenceNumber from
er> GC8

GC9 Sale: Sale Response:

<amount> 2000 <response> 000
<type> GC <message> Approved
<number> Supplied by <authCode> 11111
Implementation <cardValidationResu M
Consultant lt>
<expDate> 1220 <availableBalance> 8000
<cardValidationNum> 123

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

176
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC9A Deposit Reversal: Deposit Reversal

Response:
<cnpTxnId> Value from GC9 resp.
<type> from GC9 <response> 000
<number> from GC9 <message> Approved
<expDate> from GC9
<originalRefCode> refCode from GC9
<originalAmount> amount from GC9
<originalSystemTraceId> systemTraceId from GC9
<originalSequenceNumb sequenceNumber from
er> GC9

GC10 Sale: Sale Response:

<amount> 2000 <response> 000
<type> GC <message> Approved
<number> Number from GC9 <authCode> 11111
<expDate> 1220 <cardValidationResu M
lt>
<cardValidationNum> 123
<availableBalance> 8000

GC10A Gift Card Credit: Credit Response:

<cnpTxnId> Value from GC10 resp. <response> 000
<CreditAmount> 2000 <message> Approved
<type> GC
<number> Number from GC9
<expDate> 1220

GC10B Refund Reversal: Refund Reversal

Response:
<cnpTxnId> Value from GC10A resp.
<type> from GC10 <response> 000
<number> form GC10 <message> Approved
<expDate> from GC10
<originalRefCode> refCode from GC10A
<originalAmount> amount from GC10A
<originalSystemTraceId> systemTraceId from
GC10A
<originalSequenceNumb sequenceNumber from
er> GC10A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

177
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC11 Deactivate Reversal: Deactivate

Reversal
<cnpTxnId> Value from GC3 resp.
Response:
<type> from GC3
<number> from GC3 <response> 000
<expDate> from GC3 <message> Approved
<originalRefCode> refCode from GC3 resp.
<originalAmount> amount from GC3 resp.
<originalSystemTraceId> systemTraceId from GC3
<originalSequenceNumb sequenceNumber from
er> GC3 resp.

GC12 Load Reversal: Load Reversal

Response:
<cnpTxnId> Value from GC4 resp.
<type> from GC4 <response> 000
<number> from GC4 <message> Approved
<expDate> form GC4 <availableBalance> 0
<originalRefCode> refCode from GC4 resp.
<originalAmount> amount from GC4 resp.
<originalSystemTraceId> systemTraceId from GC4
<originalSequenceNumb sequenceNumber from
er> GC4 resp.

GC13 Unload: Unload Response:

<amount> 2500 <response> 000
<type> GC <message> Approved
<number> Supplied by <cardValidationResu M
Implementation lt>
Consultant <availableBalance> 1500
<expDate> 0121
<cardValidationNum> 123

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

178
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC13A Unload Reversal: Unload Reversal

Response:
<cnpTxnId> Value from GC13 resp.
<type> from GC13 <response> 000
<number> from GC13 <message> Approved
<expDate> from GC13
<originalRefCode> refCode from GC13 resp.
<originalAmount> amount from GC13 resp.
<originalSystemTraceId> systemTraceId from
GC13 resp.
<originalSequenceNumb sequenceNumber from
er> GC13 resp.

GC14 Activate: Activate Response:

<amount> 15000 <response> 301
<type> GC <message> Invalid Account
Number
<number> Supplied by
Implementation
Consultant
<expDate> 1221
<cardValidationNum> 123

GC15 Activate: Activate Response:

<amount> 10000 <response> 217
<type> GC <message> Already active
<number> Number from GC1 <availableBalance> 14000
<expDate> 1221
<cardValidationNum> 123

GC16 Authorization: Authorization

Response:
<amount> 1500000
<type> GC <response> 352
<number> Number from GC1 <message> Decline
CVV/CID Fail
<expDate> 1221
<cardValidationResu M
<cardValidationNum> 123
lt>
<availableBalance> 14000

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

179
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-28 Private Label Gift Card Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

GC17 Authorization: Authorization

Response:
<amount> 15000
<type> GC <response> 218
<number> Supplied by <message> Card not active
Implementation
Consultant
<expDate> 1221
<cardValidationNum> 123

GC19 Sale: Sale Response:

<amount> 1000 <response> 000
<type> GC <message> Approved
<number> Supplied by <authCode> 11111
Implementation
<cardValidationResu M
Consultant
lt>
<expDate> 1220 <availableBalance> 1500
<cardValidationNum> 123

GC19A Gift Card Credit: Credit Response:

<cnpTxnId> Value from GC19 resp. <response> 000
<creditAmount> 10000 <message> Approved
<type> GC
<number> Value from GC19 Declined Transaction
report result = 304 -
<expDate> 1220
Lost/Stolen Card

GC20 Balance Inquiry: Balance Inquiry

Response:
<type> GC
<number> Number from GC4 <response> 352
<expDate> 0121 <message> Invalid CVV2
<cardValidationNum> 476

2.5.16 Testing MasterPass Transactions

If you are planning to support MasterPass transaction, in addition to other required certification testing,
you should submit the following transactions to test the use of the additional cnpAPI elements required for
a MasterPass transaction.
To test the MasterPass functionality using the data supplied in Table 2-29:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

180
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

1. Submit an Authorization transaction using the data supplied for Order Id MCWalletAuth. Verify that
the response data matches the values for the Key Response Elements for that orderId.
2. Submit a Sale transaction using the data supplied for Order Id MCWalletSale. Verify that the
response data matches the values for the Key Response Elements for that orderId.

TABLE 2-29 MasterPass Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

MCWalletAut <wallet> (parent element) <response> 000

h
<walletSourceType> MasterPass <message> Approved
<walletSourceTypeId> 102

MCWalletSal <wallet> (parent element) <response> 000

e
<walletSourceType> MasterPass <message> Approved
<walletSourceTypeId> 102

2.5.17 Testing Apple Pay Transaction Processing

The following Apple Pay tests allow you to verify your submission of valid XML for two Apple Pay
scenarios. The first test scenario applies to the case where you decrypt the Apple Pay PKPaymentToken,
while the second scenario applies to the Worldpay decryption PKPaymentToken components submitted
in a cnpAPI transaction.

NOTE: For information about testing the submission of the PKPaymentToken using the Mobile
eProtect, please refer to the Worldpay eComm eProtect Integration Guide.

2.5.17.1 Testing the Submission of the Decrypted PKPaymentToken in cnpAPI

To test the submission of an Apple Pay transaction in cnpAPI when you decrypt the PKPaymentToken,
you must include the information listed in the table below in an Authorization or Sale transaction.
Assuming you submit valid XML with appropriate values, the test environment will return an approved
response message.

TABLE 2-30 cnpAPI Elements for Merchant Decrypted PKPaymentToken

cnpAPI Element Value

number Use any valid (Mod-10 compliant) test card

number.
expDate Use any valid expiration date (i.e., a date in the
future).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

181
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-30 cnpAPI Elements for Merchant Decrypted PKPaymentToken

cnpAPI Element Value

authenticationValue Any Base-64 encoded value between 40 and 56

characters in length. This value simulates the
cryptogram extracted from the
PKPaymentToken.
orderSource Set to applepay

2.5.17.2 Testing the Submission of PKPaymentToken in cnpAPI

When you receive a PKPaymentToken, you must parse (not decrypt) the component parts and use the
data to populate the cnpAPI <applepay> child elements. This test is designed to allow you to verify your
ability to parse the PKPaymentToken data and construct well formed cnpAPI messages. The test uses
the data from the example PKPaymentToken shown below (data element names in bold red type) to
construct an Authorization or Sale transaction (see applepay). The system returns a Response Code of
000 - Approved.

Example: PKPaymentToken
{"version":"EC_v1","data":"Ww9EI+10VVpyZrAb3nxu9c8PG4JEnIh4oTkDhZi4axj5QqC5WIir6TJcFmk/
3wkrNL/KaRXz3aan4WRO6cPL+cUTRpQUO9ECqTBItmQbJxGbN42713TyI+y97k3msl7bd5rJOMIOpkCtfp2ua+3
lnBhjGFnUzdCxq+/K6eoIEwYlAEfX9Sdpjm+plVfvSK7vj0BQCcXo1dXGkNUKwKWA4GYPUE3qwbuiQWcZwLxAEF
43274pACV4LBmdv0HYgYpcgCY0+U6/YSVKdpPrhHLDeLOlO7T4WwuimHojsKA/BknpPY1uJfP+YJxj1fYghaAOA
R0tA5cYJftlWLXaV9lZu113Ns1rxColh4PR8wsuw81CdOruvoURGNaNyX+hG1suQoHeE8ECzKIE6DlHEeVMcdxX
ySwFPY7hxEY1QKSSXw==","signature":"MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCA
BgkqhkiG9w0BBwEAAKCAMIICvzCCAmWgAwIBAgIIQpCV6UIIb4owCgYIKoZIzj0EAwIwejEuMCwGA1UEAwwlQXB
wbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgLSBHMzEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbi
BBdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMB4XDTE0MDUwODAxMjMzOVoXDTE5M
DUwNzAxMjMzOVowXzElMCMGA1UEAwwcZWNjLXNtcC1icm9rZXItc2lnbl9VQzQtUFJPRDEUMBIGA1UECwwLaU9T
IFN5c3RlbXMxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQc
DQgAEwhV37evWx7Ihj2jdcJChIY3HsL1vLCg9hGCV2Ur0pUEbg0IO2BHzQH6DMx8cVMP36zIg1rrV1O/0komJPn
wPE6OB7zCB7DBFBggrBgEFBQcBAQQ5MDcwNQYIKwYBBQUHMAGGKWh0dHA6Ly9vY3NwLmFwcGxlLmNvbS9vY3NwM
DQtYXBwbGVhaWNhMzAxMB0GA1UdDgQWBBSUV9tv1XSBhomJdi9+V4UH55tYJDAMBgNVHRMBAf8EAjAAMB8GA1Ud
IwQYMBaAFCPyScRPk+TvJ+bE9ihsP6K7/S5LMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwuYXBwbGUuY29
tL2FwcGxlYWljYTMuY3JsMA4GA1UdDwEB/wQEAwIHgDAPBgkqhkiG92NkBh0EAgUAMAoGCCqGSM49BAMCA0gAME
UCIQCFGdtAk+7wXrBV7jTwzCBLE+OcrVL15hjif0reLJiPGgIgXGHYYeXwrn02Zwcl5TT1W8rIqK0QuIvOnO1TH
CbkhVowggLuMIICdaADAgECAghJbS+/OpjalzAKBggqhkjOPQQDAjBnMRswGQYDVQQDDBJBcHBsZSBSb290IENB
IC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmM
uMQswCQYDVQQGEwJVUzAeFw0xNDA1MDYyMzQ2MzBaFw0yOTA1MDYyMzQ2MzBaMHoxLjAsBgNVBAMMJUFwcGxlIE
FwcGxpY2F0aW9uIEludGVncmF0aW9uIENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmljYXRpb24gQXV0a
G9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BPAXEYQZ12SF1RpeJYEHduiAou/ee65N4I38S5PhM1bVZls1riLQl3YNIk57ugj9dhfOiMt2u2ZwvsjoKYT/VEW
jgfcwgfQwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vb2NzcC5hcHBsZS5jb20vb2NzcDA0LW
FwcGxlcm9vdGNhZzMwHQYDVR0OBBYEFCPyScRPk+TvJ+bE9ihsP6K7/S5LMA8GA1UdEwEB/wQFMAMBAf8wHwYDV
R0jBBgwFoAUu7DeoVgziJqkipnevr3rr9rLJKswNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC5hcHBsZS5j
b20vYXBwbGVyb290Y2FnMy5jcmwwDgYDVR0PAQH/BAQDAgEGMBAGCiqGSIb3Y2QGAg4EAgUAMAoGCCqGSM49BAM
CA2cAMGQCMDrPcoNRFpmxhvs1w1bKYr/0F+3ZD3VNoo6+8ZyBXkK3ifiY95tZn5jVQQ2PnenC/gIwMi3VRCGwow
V3bF3zODuQZ/0XfCwhbZZPxnJpghJvVPh6fRuZy5sJiSFhBpkPCZIdAAAxggFfMIIBWwIBATCBhjB6MS4wLAYDV
QQDDCVBcHBsZSBBcHBsaWNhdGlvbiBJbnRlZ3JhdGlvbiBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMCCEKQlelCCG+KMA0GCWC

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

182
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

GSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQxMDAzMjE1Nj
QzWjAvBgkqhkiG9w0BCQQxIgQgg8i4X6yRAU7AXS1lamCf02UIQlpUvNPToXUaamsFUT8wCgYIKoZIzj0EAwIER
zBFAiBe17NGTuuk+W901k3Oac4Z90PoMhN1qRqnij9KNEb/XAIhALELZyDWw0fQM8t0pXO86gg9xXFz424rEMlJ
01TM1VxhAAAAAAAA","header":{"applicationData":"496461ea64b50527d2d792df7c38f301300085dd
463e347453ae72debf6f4d14","transactionId":"f9b0d3cfbb64cd155249c691aca3c521de0372572061
6b810d90341f97f347b7","ephemeralPublicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEarp8xOh
LX9QliUPS9c54i3cqEfrJD37NG75ieNxncOeFLkjCk","publicKeyHash":"jAMRQqg4nffHrXvfwRfbaEc11b
k3QD3rv5K9xLqLgu0="}}

2.5.18 Testing Google Pay Transaction Processing

The certification testing you need to perform depends upon the integration method you implement. This
section provides information about the required tests for the eProtect integration method.
If you are experiencing an issue with your production Google Pay API setup, contact the gTech Ops
Team for resolution here: https://developers.google.com/pay/api/support/how-to-get-help. You can find
additional information and help at the Google Developer’s site:
https://payments.google.com/solutions/onboarding/.

2.5.18.1 Testing Google Pay using eProtect

In this integration method, your application submits information to the Google test environment, receives a
low-value token, and then submits the low value token to Worldpay in a normal payment transaction.
The table below provides key data values you provide in the submitted transaction.
1. Perform an implicit token registration by submitting a Sale or Authorization transaction using the data
shown for the androidpay_1 (orderId) transaction in Table 1.
2. Verify the response message includes the key Response values shown.
3. Perform an explicit token registration by submitting a Register Token Request using the data shown
for the androidpay_2 (orderId) transaction in Table 1.
4. Verify the response message includes the key Response values shown.

TABLE 2-31 Google Pay using eProtect Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

androidpay_1 <orderSource> androidpay <response> 000

<paypageRegistrationId> Value returned from <message> Approved
Google

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

183
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-31 Google Pay using eProtect Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

androidpay_2 <paypageRegistrationId> Value returned from <response> 801

Google
<message> Account number
was successfully
registered
Note: Under
certain
circumstances this
test could return
820 - Account
number was
previously
registered.

Example: Google Pay Authorization Transaction

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<authorization id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>androidpay_1</orderId>
<amount>40000</amount>
<orderSource>androidpay</orderSource>
<paypage>
<paypageRegistrationId>Low-Value Token</paypageRegistrationId>
</paypage>
</authorization>
</cnpOnlineRequest>

2.5.19 Testing Amazon Pay

This section provides information about required Worldpay certification testing for merchants using
Amazon Pay as a method of payment. Prior to performing the certification tests detailed in this document,
you should complete all required integration with Amazon Pay and have access to their test environment.

NOTE: The instructions and test information contained in this section reflect element from the V12.x
schema. If you use an older version of the schema, you must replace V12.x elements with elements
from your version of the API. For example, the cnpTxnId element in V12.x was litleTxnId in
pre-V12 versions of the schema and cnpToken was litleToken.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

184
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

To test Amazon Pay transactions:

1. Obtain a valid Amazon Pay token and submit an authorization transaction using the token and
data from the Supplied Data Elements for Order Id AmznPay_1. Use any valid token for the
cnpToken value. Verify the transaction approves.
2. Submit a capture transaction for Order Id AmznPay_1A using the cnpTxnId value returned in the
response messages for Authorization Order Id AmznPay_1. Verify the transaction approves.
3. Submit a credit transaction for Order Id AmznPay_1B using the cnpTxnId value returned in the
response messages for Authorization Order Id AmznPay_1A. Verify the transaction approves.
4. Submit a void transaction for Order Id AmznPay_1C using the cnpTxnId value returned in the
response messages for Authorization Order Id AmznPay_1B. Verify the transaction approves.
5. Obtain a valid Amazon Pay token and submit a sale transaction using the token and data from the
Supplied Data Elements for Order Id AmznPay_2. Use any valid token for the cnpToken value.
Verify the transaction approves.
6. Obtain an Amazon Pay token (from Amazon Pay) that generates a 560 Response Code and submit
either an authorization or a sale transaction using the token and data from the Supplied Data
Elements for Order Id AmznPay_560. Verify your system handles the 560 response code correctly.
7. Obtain an Amazon Pay token (from Amazon Pay) that generates a 561 Response Code and submit
either an authorization or a sale transaction using the token and data from the Supplied Data
Elements for Order Id AmznPay_561. Verify your system handles the 561 response code correctly.
8. Submit either an authorization or a sale transaction using the data from the Supplied Data
Elements for Order Id AmznPay_562. Verify your system handles the 562 response code correctly.
9. Submit either an authorization or a sale transaction using the data from the Supplied Data
Elements for Order Id AmznPay_563. Verify your system handles the 563 response code correctly.
10. Submit either an authorization or a sale transaction using the data from the Supplied Data
Elements for Order Id AmznPay_110. Verify your system handles the 110 response code correctly.

TABLE 2-32 Amazon Pay Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

AmznPay_1 Authorization: Authorization

Response:
<amount> 10100
<response> 000
<cnpToken> xxxxxxxxxxxxAMZN
<message> Approved

AmznPay_1A Capture: Capture Response:

<cnpTxnId> Value returned in <response> 000
Auth response for <message> Approved
Order Id AmznPay_1

AmznPay_1B Credit: Credit Response:

<cnpTxnId> Value returned in <response> 000
Capture response for <message> Approved
Order Id Amzn_1A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

185
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-32 Amazon Pay Test Data (Continued)

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

AmznPay_1C Void: Void Response:

<cnpTxnId> Use either the value <response> 000
returned in the Credit <message> Approved
response for Order Id
AmznPay_1B (not
Auth).

AmznPay_2 Sale: Authorization

Response:
<amount> 10100
<response> 000
<number> xxxxxxxxxxxxAMZN
<message> Approved

AmznPay_560 Authorization: Authorization

Response:
<amount> 56000
<response> 560
<cnpToken> 560000000000AMZN
<message> Soft Decline - System
Error - Contact
Worldpay
representative

AmznPay_561 Authorization: Authorization

Response:
<amount> 56100
<response> 561
<cnpToken> 561111111111AMZN
<message> Soft Decline -
Amazon Pay -
Amazon Unavailable

AmznPay_562 Authorization: Authorization

Response:
<amount> 56200
<response> 562
<cnpToken> 562222222222AMZN
<message> Hard Decline -
Amazon Pay -
Amazon Declined

AmznPay_563 Authorization: Authorization

Response:
<amount> 56300
<response> 563
<cnpToken> 563333333333AMZN
<message> Hard Decline -
Amazon Pay - Invalid
Token

AmznPay_110 Authorization: Authorization

Response:
<amount> 11000
<response> 110
<cnpToken> 110000000000AMZN
<message> Insufficient funds

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

186
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.20 Testing checkoutId

The checkoutId element is a low value token issued by eProtect in replacement for the CVV value. You
only need to perform these test if you use eProtect and plan to use the checkoutId in place of the CVV.
To test the use of the checkoutId element, do the following:
The first test provides a response of a matching CVV, while the second and third test return checkoutId
failure messages allowing you to verity your handling of these conditions. All tests return as Approved,
because the CVV check does not necessarily impact the approval/decline of a transaction.
1. Using your (test) Web site, the token value returned for orderId 1 (Table 2-1) and the CVV value
shown for orderId 1 to initiate an eProtect transaction. Use the checkoutId value you receive for
CVV to construct an Authorization transaction within 24 hours. Verify the response data matches the
information shown for orderId chkoutId_1 in Table 2-33.
2. Submit an Authorization using the same token value from Step 1 and the checkoutId value from the
Supplied Data Elements for orderId chkoutId_2. Verify that the response data matches the Key
response Elements for orderId chkoutId_2 in Table 2-33.
3. Submit an Authorization using the same token value from Step 1 and the checkoutId value from the
Supplied Data Elements for orderId chkoutId_3. Verify that the response data matches the Key
response Elements for orderId chkoutId_3 in Table 2-33.

TABLE 2-33 checkoutId Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

chkoutId_1 <cnpToken> value from orderId_1 <response> 000

<checkoutId> value from eProtect <message> Approved
<cardValidationResult> M

chkoutId_2 <cnpToken> value from orderId_1 <response> 000

<checkoutId> A90999999999999999 <message> Approved
<tokenResponseCode> 826
<tokenMessage> Checkout Id was
invalid

chkoutId_3 <cnpToken> value from orderId_1 <response> 000

<checkoutId> 201234567891234567 <message> Approved
<tokenResponseCode> 827
<tokenMessage> Checkout Id was
not found

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

187
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

2.5.21 Testing Encrypted Card and CVV in Register Token Requests

If you plan to submit an encrypted account number and/or card validation number in your Register Token
request, you must certify your transactions using the following procedure.
To test using an encrypted account number and/or card validation number in your Register Token
request:
1. Obtain the latest key from this URL: https://request.eprotect.vantivprelive.com/eProtect/keys.json. The
URL displays information similar to the following:
{"publicKey":{"modulus":"bc637dd74ba76507dad5af1c7ad6f97dbef5298c3b9f74caea7301347db7b4
a8c37f26491863100667246fd45071f3346bf62239f9b117d06fb67861b66ad0d158beeddd2f6f28be93d84
6f4c8f9ba1bd7e8f186f36cab0e432f22b3d732c221a9ff00a9bfacb88b24503e2695fd7237835d4936477b
21289478906a49b164f52503c20eb29f11fcbda2af94deb9a0bfde5a4589276897436315c5d664d60bf1065
0164f509283aed39747ad5d6cb2bbe54e1b42306e5db37dfd42dcbfcc689e0ddfe3bc9cb22ae7018e5a4a1f
f39813584ac7bd6d6d65ca763f0a672da454081ea20e8b1d403316d80b9353ba396bea8962b1a7d2f775c76
612d857c1f7594f","exponent":"10001","keyId":"1"},"visaCheckout":{"apiKey":"UHTJ5A1SMG3P
C81Y1CJT13x6XM0ekIIdixNrIMcPe8KI4GgNg"}}

NOTE: The key changes daily. In the production environment, each key expires after 1 year. Keys
do not expire in the Pre-Live environment.

2. Verify that your cnpAPI template is coded correctly for this transaction type (refer to Register Token
Transactions on page 292.)
3. Using the data for Order Ids encrypted_1 through encrypted_4 from Table 2-34 and the key
information from the URL, encrypt the supplied values using RSA-OAEP SHA1.
4. Verify that your registerTokenResponse values match those shown in the Key Response
Elements section of Table 2-34. The complete token values are not defined in the table, because the
system generates the tokens dynamically according to your token scheme.

TABLE 2-34 Encrypted Register Token Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

encrypt <encryptionKeyId> Value from URL <cnpToken> value per token

_1 scheme
<encryptedAccountNumber> Encrypt this value:
4457119922390123 <bin> 445711
<encryptedCardValidationNum> Encrypt this value: <type> VI
367 <response> 801
<message> Account number
was successfully
registered

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

188
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

TABLE 2-34 Encrypted Register Token Test Data

Supplied Data Elements Key Response Elements

orderId Element Value Element Value

encrypt <encryptionKeyId> Value from URL <cnpToken> none returned

_2
<encryptedAccountNumber> Encrypt this value: <response> 820
4457119999999999 <message> Credit card number
<encryptedCardValidationNum> None was invalid

encrypt <encryptionKeyId> Value from URL <cnpToken> value per token

_3 scheme
<encryptedAccountNumber> Encrypt this value:
4457119922390123 <bin> 445711
<encryptedCardValidationNum> Encrypt this value: <type> VI
367 <response> 802
<message> Account number
was previously
registered

encrypt <encryptionKeyId> Value from URL <response> 540

_4
<encryptedAccountNumber> Encrypt this value: <message> Hard Decline -
4457119922390123 Decryption Failed
, but change one
character in the
encrypted value.
<encryptedCardValidationNum> Encrypt this value:
367

2.5.22 Testing Transaction Volume Capacity

Volume testing is useful if you plan to send large files. This is an optional test you can perform during
certification testing. Volume testing enables you to verify how many transactions (the number of requests
and responses) you can process within a specific time frame.
Worldpay, Inc. recommends you submit transactions for a 15-minute time interval. Submit the
approximate number of transactions that you anticipate to be normal volume for any 15-minute period.
You can send in any valid transaction data; the actual data you send will not be verified.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

189
© 2020 FIS and/or its affiliates. All rights reserved.
 Testing Your cnpAPI Transactions

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

190
© 2020 FIS and/or its affiliates. All rights reserved.
 3
cnpAPI Transaction Examples

This chapter contains information and examples concerning the structure of cnpAPI transaction
messages. Where differences exist between the structure of Batch and Online transactions, the sections
present examples of both structures.

NOTE: n the cnpAPI, the order of the elements is enforced. Failure to adhere to the element order
as defined in the schema will result in XML validation errors.

This chapter discusses the following topics:

• Overview of Online and Batch Processing Formats
• Transaction Types and Examples

NOTE: This chapter does not include examples of the PayFac Instruction-Based Dynamic Payout
transaction types. For additional information about these transactions, please refer to Appendix D,
"PayFac Dynamic Payout".

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

191
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.1 Overview of Online and Batch Processing Formats

There are two methods of submitting payment transactions using the cnpAPI format: Online (one
transaction at a time), or Batch. This section provides a high level overview of the request and response
structures used for each submission type.

3.1.1 Batch Process Format

We treat each Batch transmission you send to us as a single request. You can think of the entire Batch
request as a session composed of one or more individual batches, each containing one or more
transactions. You can also use a Batch as a retrieval request for the response to a previously processed
session. We return a response transmission for each request.
Batch processing supports the following transaction types:

• Activate Transactions • eCheck Verification Transactions

• Authorization Transactions • Force Capture Transactions
• Authorization Reversal • Fraud Check Transaction
• Balance Inquiry Transactions • Gift Card Auth Reversal Transaction
• Cancel Subscription Transactions • Gift Card Capture Transaction
• Capture Transactions • Gift Card Credit Transaction
• Capture Given Auth Transactions • Load Transactions
• Create Plan Transactions • Register Token Transactions
• Credit Transactions • RFR Batch Transactions (Batch Only)
• Deactivate Transactions • Sale Transactions
• eCheck Credit Transactions • Unload Transactions
• eCheck Prenotification Credit • Update Card Validation Number Transactions
• eCheck Prenotification Sale • Update Plan Transactions
• eCheck Redeposit Transactions • Update Subscription Transactions
• eCheck Sale Transactions • All PayFac Dynamic Payout Transactions

NOTE: For information and examples of Dynamic Payout Funding Instructions, please refer to
Appendix D, "PayFac Dynamic Payout".

For more information about Batch processing, see Batch Transaction Processing on page 5.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

192
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.1.1.1 Supported Communication Protocols

We supports the following communication protocols for Batch processing:

• sFTP
For additional information concerning the recommended transmission methods, see Transferring Session
Files on page 88.

3.1.1.2 Batch Processing Request Format

The Batch processing request is made up of the following elements:

• Header information - one <cnpRequest> element
• Merchant authentication information - one <authentication> element
• Batch information - one or more <batchRequest> elements
• Payment transactions (for example, an Authorization, Capture, Credit, etc.) - at least one per
<batchRequest> element

NOTE: Each of the num and amount attributes used in a batchRequest defaults to 0 (zero) if not
specified in the request. In any of the amount fields (authAmount, captureAmount, etc.), the
value is an implied decimal (for example 500=5.00).

3.1.1.3 Batch Processing Response Format

The Batch processing response is composed of the following elements:

• Header information - one <cnpResponse> element
• One or more <batchResponse> elements - contains payment transactions response.
• At least one payment transaction response (for example, an Authorization response, Capture
response, Credit response, etc.).

NOTE: For information on the XML Validation response and message attributes, please refer to
XML Validation Error Messages on page 880.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

193
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.2 Online Processing Format

Each Online request you send to us is a single transaction. We process Online transactions upon receipt
and return a response file.

CAUTION: If you use Open Access (i.e., Transact) to submit Online transactions, you must limit the
message size to a maximum of 20K characters. We reject any transaction containing more than 20K
characters with a XML validation response value of 5 (see Additional Response Header Error
Messages on page 882).

Online processing supports the following transaction types:

• Activate Transactions
• Activate Reversal Transactions (Online Only)
• Authorization Transactions
• Authorization Reversal
• Balance Inquiry Transactions
• Cancel Subscription Transactions
• Capture Transactions
• Capture Given Auth Transactions
• Create Plan Transactions
• Credit Transactions
• Deactivate Transactions
• Deactivate Reversal Transactions (Online Only)
• Deposit Reversal Transactions (Online Only)
• Force Capture Transactions
• Load Transactions
• Load Reversal Transactions (Online Only)
• eCheck Sale Transactions
• eCheck Credit Transactions
• eCheck Redeposit Transactions
• eCheck Verification Transactions
• eCheck Void Transactions (Online Only)
• Refund Reversal Transactions (Online Only)
• Sale Transactions
• Status Query Transaction (Online Only)
• Unload Transactions
• Unload Reversal Transactions (Online Only)
• Update Card Validation Number Transactions
• Update Plan Transactions

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

194
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

• Update Subscription Transactions

• Void Transactions (Online Only)

3.2.1 Supported Communication Protocols

Worldpay, Inc. supports the HTTPS POST communication protocol for Online processing.
For additional information concerning the recommended transmissions methods, see Transferring Online
Files on page 89.

3.2.2 Online Processing Request Format

The Online processing request is made up of the following elements:
• Header information - one <cnpOnlineRequest> element
• Merchant authentication information - one <authentication> element
• Payment transaction - one payment transaction

3.2.3 Online Processing Response Format

An Online processing response is composed of the following elements:
• Header information - one <cnpOnlineResponse>
• Payment transaction - one payment transaction

NOTE: For information on the XML Validation response and message attributes, please refer to
XML Validation Error Messages on page 880.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

195
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3 Transaction Types and Examples

This section presents structural information of each transaction type for both Online and Batch
submission methods. The structural information is followed by one or more examples of the cnpAPI
transaction. Each structural example shows the parent and all child elements, but does not show
grandchildren. The cnpAPI examples do show child elements to multiple levels.
The element names in the structural examples provide links to the element definitions in Chapter 4.

NOTE: The XML examples in this section are intended to present typical cnpAPI transactions. The
examples may not include every possible element for a particular transaction type. When coding
your XML, always consult the cnpAPI schema files for information concerning all available elements.

This section contains examples of the following transaction types:

NOTE: In the cnpAPI, the order of the elements is enforced. Failure to adhere to the element order
as defined in the schema will result in XML validation errors.

• Authorization Transactions
• Authorization Reversal Transactions
• Activate Transactions (Private Label Gift Card transaction)
• Activate Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• Balance Inquiry Transactions (Private Label Gift Card transaction)
• Cancel Subscription Transactions (Recurring Engine transaction)
• Capture Transactions
• Capture Given Auth Transactions
• Create Plan Transactions (Recurring Engine transaction)
• Credit Transactions
• Deactivate Transactions (Private Label Gift Card transaction)
• Deactivate Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• Deposit Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• eCheck Credit Transactions
• eCheck Prenotification Credit Transactions (Batch Only)
• eCheck Prenotification Sale Transactions (Batch Only)
• eCheck Redeposit Transactions
• eCheck Sale Transactions
• eCheck Verification Transactions
• eCheck Void Transactions (Online Only)
• Force Capture Transactions
• Fraud Check Transaction

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

196
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

• Gift Card Auth Reversal Transactions (Private Label Gift Card transaction)
• Gift Card Capture Transactions (Private Label Gift Card transaction)
• Gift Card Credit Transactions (Private Label Gift Card transaction)
• Load Transactions (Private Label Gift Card transaction)
• Load Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• Status Query Transactions (Online Only)
• Refund Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• Register Token Transactions
• RFR Transactions (Batch Only)
• Sale Transactions
• Translate to Low Value Token Transaction
• Unload Transactions (Private Label Gift Card transaction)
• Unload Reversal Transactions (Online Only) (Private Label Gift Card transaction)
• Update Plan Transactions (Recurring Engine transaction)
• Update Subscription Transactions (Recurring Engine transaction)
• Update Card Validation Number Transactions
• Void Transactions (Online Only)

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

197
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.1 Authorization Transactions

The Authorization transaction enables you to confirm that a customer has submitted a valid payment
method with their order and has sufficient funds to purchase the goods or services they ordered.
The lifespan of an authorization varies according to the payment type being used, as shown in Table 3-1.
During the lifespan, you can use a valid authorization multiple times as needed.

NOTE: To submit an AVS Only request, submit an Authorization request with the <amount>
element set to 000. The response is identical to an Authorization response message.

TABLE 3-1 Lifespan of a Payment Authorization

Payment Type Lifespan of Authorization

American Express 7 days

Discover 10 days

Mastercard 7 days

PayPal 29 days total; Worldpay recommends three days. For more

information about PayPal authorizations, see the Worldpay eComm
PayPal Integration Guide.

Visa 7 days

This section describes the format you must use for an Authorization request, as well as the format of the
Authorization Response you receive from us.

3.3.1.1 Authorization Request Structure

You must structure an Authorization request as shown in the following examples. The structure of an
Authorization request is identical for either an Online or a Batch submission.
<authorization id="Authorization Id" reportGroup="iQ Report Group" customerId="Customer
Id">
<orderId>Order Id</orderId>
<amount>Authorization Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<orderSource>Order Entry Source</orderSource>
<customerInfo>
<billToAddress>
<shipToAddress>
[ <card> | <paypal> | <paypage> | <token> | <mpos> | <applepay>]
<cardholderAuthentication>
<processingInstructions>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

198
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<pos>
<customBilling>
<taxType>payment or fee</taxType>
<enhancedData>
<allowPartialAuth>
<healthcareIIAS>
<lodgingInfo>
<filtering>
<merchantData>
<recyclingRequest> (for Recovery merchants using Recycling)
<fraudFilterOverride>
<recurringRequest> (for Recurring Engine merchants)
<debtRepayment>true or false</debtRepayment>
<advancedFraudChecks>
<wallet>
<processingType>processingType Enum</processingType>
<originalNetworkTransactionId>Network Txn Value</originalNetworkTransactionId>
<originalTransactionAmount>Amount from Orig Txn</originalTransactionAmount>
<paymentAccountReferenceNumber>Correlation Value</paymentAccountReferenceNumber>
<pinlessDebitRequest>
<skipRealtimeAU>True or False</skipRealtimeAU>
<merchantCategoryCode>MCC Value</merchantCategoryCode>
</authorization>

Example: Batch Authorization Request - Card Not Present

The example below shows a batch request with a single card-not-present Authorization request. If the
batch included additional Authorization requests, each would have it’s own <authorization> element
with all applicable attributes and child elements. Also, the numAuths attribute of the <batchRequest>
element would increment for each additional <authorization> element and the authAmount attribute
would increase by the new amounts from each authorization.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests = "1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest numAuths="1" authAmount="2500" merchantId="000902">
<authorization id="test1" reportGroup="core" customerId="test1">
<orderId>visa_test1</orderId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

199
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<amount>2500</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</billToAddress>
<shipToAddress>
<name>Jane Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</shipToAddress>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>1110</expDate>
</card>
<customBilling>
<phone>8009990001</phone>
<descriptor>bdi*001</descriptor>
</customBilling>
<allowPartialAuth>true</allowPartialAuth>
</authorization>
</batchRequest>
</cnpRequest>

Example: Batch Authorization Request - Card Present

The following example contains two Authorization requests, each defined in its own <authorization>
element. The first is a card present transaction, which uses the <track> child of the <card> element.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

200
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<password>password</password>
</authentication>
<batchRequest id="01234567" numAuths="2" authAmount="68336" merchantId="100">
<authorization id="AX54321678" reportGroup="RG27">
<orderId>12z58743y1</orderId>
<amount>12522</amount>
<orderSource>retail</orderSource>
<billToAddress>
<zip>95032</zip>
</billToAddress>
<card>
<track>%B40000001^Doe/JohnP^06041...?;40001=0604101064200?</track>
</card>
<pos>
<capability>magstripe</capability>
<entryMode>completeread</entryMode>
<cardholderId>signature</cardholderId>
</pos>
</authorization>
<authorization id="AX54325432" reportGroup="RG12">
<orderId>12z58743y7</orderId>
<amount>55814</amount>
<orderSource>retail</orderSource>
<billToAddress>
<zip>01854</zip>
</billToAddress>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0911</expDate>
</card>
<pos>
<capability>keyedonly</capability>
<entryMode>keyed</entryMode>
<cardholderId>directmarket</cardholderId>
</pos>
<allowPartialAuth>true</allowPartialAuth>
</authorization>
</batchRequest>
</cnpRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

201
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Online Authorization Request

NOTE: The example below uses 3dsAuthenticated as the <orderSource> value. If you
submit the wrong <orderSource> value, we return the response code 370 - Internal System Error
- Contact Vantiv.
Also, the values for the <authenticationValue> and <authenticationTransactionId>
elements in the example are truncated.

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"

merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<authorization id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>3dsAuthenticated</orderSource>
<billToAddress>
<name>John Smith</name>
<addressLine1>100 Main St</addressLine1>
<city>Boston</city>
<state>MA</state>
<zip>12345</zip>
<email>[email protected]</email>
<phone>555-123-4567</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4000000000000002</number>
<expDate>1209</expDate>
<cardValidationNum>555</cardValidationNum>
</card>
<cardholderAuthentication>
<authenticationValue>BwABBJQ1gJDUCAAAAAAA=</authenticationValue>
<authenticationTransactionId>gMV75TmjAgk=</authenticationTransactionId>
</cardholderAuthentication>
</authorization>
</cnpOnlineRequest>

Example: Authorization Request using token Element

The example below uses the following token related elements (click name to jump to element definition):
token and cnpToken.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

202
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts
and stores the value temporarily for later use in a tokenized Auth/Sale transaction submitted without
the value. To use the store value when submitting an Auth/Sale transaction, set the
cardValidationNum value to 000.

<authorization id="99999" customerId="444" reportGroup="RG1">

<orderId>F12345</orderId>
<amount>15000</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</billToAddress>
<shipToAddress>
<name>Jane Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</shipToAddress>
<token>
<cnpToken>1111000101039449</cnpToken>
<expDate>1112</expDate>
<cardValidationNum>987</cardValidationNum>
</token>
</authorization>

Example: Authorization Request with Recurring Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

203
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<authorization id="834262" reportGroup="ABC Division" customerId="038945">

<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>3dsAuthenticated</orderSource>
<billToAddress>
<name>John Smith</name>
<addressLine1>100 Main St</addressLine1>
<city>Boston</city>
<state>MA</state>
<zip>12345</zip>
<email>[email protected]</email>
<phone>555-123-4567</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4000000000000002</number>
<expDate>1209</expDate>
<cardValidationNum>555</cardValidationNum>
</card>
<cardholderAuthentication>
<authenticationValue>BwABBJQ1gJDUCAAAAAAA=</authenticationValue>
<authenticationTransactionId>gMV75TmjAgk=</authenticationTransactionId>
</cardholderAuthentication>
<recurringRequest>
<subscription>
<planCode>Gold_Monthly_1</planCode>
<numberOfPayments>12</numberOfRemianingPayments>
<startDate>2016-07-21</startDate>
<amount>1500</amount>
<createDiscount>
<discountCode>New_Customer_Discount_1</addOnCode>
<name>New_Customer</name>
<amount>750</amount>
<startDate>2016-07-21</startDate>
<endDate>2016-07-22</endDate>
</createDiscount>
<createAddOn>
<addOnCode>Extra_Feature_1</addOnCode>
<name>Extra_1</name>
<amount>900</amount>
<startDate>2016-08-21</startDate>
<endDate>2016-07-21</endDate>
</createAddOn>
</subscription>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

204
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</recurringRequest>
</authorization>
</cnpOnlineRequest>

3.3.1.2 Authorization Response Structure

An Authorization response has the following structure. The response message is identical for Online and
Batch transactions except Online includes the <postDate> element.
<authorizationResponse id="Authorization Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<orderId>Order Id</orderId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<authCode>Approval Code</authCode>
<approvedAmount>Approved amount for partial Auth<approvedAmount>
<accountInformation>
<accountUpdater>
<fraudResult>
<tokenResponse> (for Tokenized merchants submitting card data)
<enhancedAuthResponse>
<recyclingResponse> (included for declined Auths if feature is enabled)
<recurringResponse> (for Recurring Engine merchants)
<giftCardResponse> (included if Gift Card is Method of Payment)
<applepayResponse>
<cardSuffix>Card Last 4</cardSuffix> (included for ApplePay using VI or MC)
<androidpayResponse>
<networkTransactionId>Txn ID returned from network</networkTransactionId>
<paymentAccountReferenceNumber>Correlation Value</paymentAccountReferenceNumber>
pinlessDebitResponse
</authorizationResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

205
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Batch Authorization Response

The example below shows a batch Authorization response that contains two transactions.
<cnpResponse version="12.3" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<authorizationResponse id="AX54321678" reportGroup="RG27">
<cnpTxnId>84568456</cnpTxnId>
<orderId>12z58743y1</orderId>
<response>000</response>
<responseTime>2011-03-01T10:24:31</responseTime>
<message>Approved</message>
<authCode>123456</authCode>
<fraudResult>
<avsResult>00</avsResult>
</fraudResult>
</authorizationResponse>
<authorizationResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<orderId>12z58743y7</orderId>
<response>000</response>
<responseTime>2017-09-01T10:24:31</responseTime>
<message>Approved</message>
<authCode>123456</authCode>
<fraudResult>
<avsResult>00</avsResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
<enhancedAuthResponse>
<fundingSource>
<type>PREPAID</type>
<availableBalance>5000</availableBalance>
<reloadable>NO</reloadable>
<prepaidCardType>GIFT</prepaidCardType>
</fundingSource>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>
</authorizationResponse>
</batchResponse>
</cnpResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

206
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Online Authorization Response including Advanced Fraud Results

NOTE: The online response format contains a <postDate> element, which indicates the date the
financial transaction will post.

<cnpOnlineResponse version="12.12" xmlns="http://www.vantivcnp.com/schema"

response="0" message="Valid Format" location="denver">
<authorizationResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>969506</cnpTxnId>
<orderId>65347567</orderId>
<response>000</response>
<responseTime>2020-01-25T15:13:43</responseTime>
<postDate>2020-01-25</postDate>
<message>Approved</message>
<authCode>123457</authCode>
<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>N</cardValidationResult>
<authenticationResult>2</authenticationResult>
<advancedFraudResults>
<deviceReviewStatus>pass</deviceReviewStatus>
<deviceReputationScore>70</deviceReputationScore>
<triggeredRule>FlashImagesCookiesDisabled</triggeredRule>
</advancedFraudResults>
</fraudResult>
<enhancedAuthResponse>
<fundingSource>
<type>PREPAID</type>
<availableBalance>0</availableBalance>
<reloadable>YES</reloadable>
<prepaidCardType>TEEN</prepaidCardType>
</fundingSource>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>
<paymentAccountReferenceNumber>123456789</paymentAccountReferenceNumber>
</authorizationResponse>
</cnpOnlineResponse>

Example: Authorization Response for Tokenized Merchant Sending Card Data

If a tokenized merchant submits card data in the Authorization request, the response includes the
tokenResponse element. The example below is a response for an Online request
(cnpOnlineResponse element not shown); therefore, it includes the postDate element.
<authorizationResponse id="99999" reportGroup="RG1" customerId="444">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

207
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>21200000001108</cnpTxnId>
<orderId>F12345</orderId>
<response>000</response>
<responseTime>2017-10-08T21:38:32</responseTime>
<postDate>2017-10-08</postDate>
<message>Approved</message>
<authCode>270005</authCode>
<fraudResult>
<avsResult>11</avsResult>
<cardValidationResult>P</cardValidationResult>
</fraudResult>
<tokenResponse>
<cnpToken>1111100100240005</cnpToken>
<tokenResponseCode>801</tokenResponseCode>
<tokenMessage>Account number was successfully registered</tokenMessage>
<type>VI</type>
<bin>402410</bin>
</tokenResponse>
</authorizationResponse>

Example: Online Authorization Response with Account Updater Token Info

In this example. the <accountUpdater> contains both original and new card information as well as the
<extendedCardResponse> element. This signifies that the card number changed from the original to
the new and (from the extended response code) that the issuer reported the new account as closed.
Although the Authorization was approved, this information allows you to make an informed decision about
how to proceed with the sale.
<cnpOnlineResponse version="12.12" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format" location="denver">
<authorizationResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>969506</cnpTxnId>
<orderId>65347567</orderId>
<response>000</response>
<responseTime>2020-01-25T15:13:43</responseTime>
<postDate>2020-01-25</postDate>
<message>Approved</message>
<authCode>123457</authCode>
<accountUpdater>
<originalCardTokenInfo>
<cnpToken>1111100100240005</cnpToken>
<type>VI</type>
<expDate>1112</expDate>
<bin>400555</bin>
</originalCardTokenInfo>
<newCardTokenInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

208
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpToken>1111100100250017</cnpToken>
<type>VI</type>
<expDate>1114</expDate>
<bin>400555</bin>
</newCardTokenInfo>
<extendedCardResponse>
<code>501</code>
<message>The account was closed</message>
</extendedCardResponse>
</accountUpdater>
<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>N</cardValidationResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
</authorizationResponse>
</cnpOnlineResponse>

Example: Online Authorization Response with Recurring Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<authorizationResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>969506</cnpTxnId>
<orderId>65347567</orderId>
<response>000</response>
<responseTime>2017-09-25T15:13:43</responseTime>
<postDate>2017-09-25</postDate>
<message>Approved</message>
<authCode>123457</authCode>
<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>N</cardValidationResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
<recurringResponse>
<subscriptionId>1234567890</subscriptionId>
<responseCode>000</responseCode>
<responseMessage>Approved</responseMessage>
</recurringResponse>
</authorizationResponse>
</cnpOnlineResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

209
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.2 Authorization Reversal Transactions

The Authorization Reversal transaction enables you to remove the hold on any funds being held by an
Authorization. The original Authorization transaction must have been processed within the system. For
information on how to use the Authorization Reversal transaction, see Notes on the Use of Authorization
Reversal Transactions on page 71. Also, if you use our Recycling Engine, you can use the
authReversal transaction to halt the recycling of an authorization transaction.

NOTE: To reverse an Authorization on a Closed-loop Gift Card, submit a Gift Card Auth Reversal
transaction, not an Authorization Reversal transaction. See Gift Card Auth Reversal Transactions on
page 276 for additional information.

3.3.2.1 Authorization Reversal Requests

You must structure an Authorization Reversal request as shown in the following examples. The structure
of the request is identical for either an Online or a Batch submission.
<authReversal id="Authorization Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<amount>Authorization Amount to Reverse</amount>
<actionReason>SUSPECT_FRAUD</actionReason>
</authReversal>

Example: Batch Authorization Reversal Request

The following example contains three Authorization Reversal Requests.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest numAuthReversals="3" authReversalAmount="3005"
merchantId="000057">
<authReversal id="ID" customerId="customerId" reportGroup="000057">
<cnpTxnId>12345678</cnpTxnId>
<amount>1002</amount>
</authReversal>
<authReversal id="ID" customerId="customerId" reportGroup="000057">
<cnpTxnId>81234567</cnpTxnId>
<amount>1003</amount>
</authReversal>
<authReversal id="ID" customerId="customerId" reportGroup="000057">
<cnpTxnId>78123456</cnpTxnId>
<amount>1000</amount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

210
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</authReversal>
</batchRequest>
</cnpRequest>

Example: Online Authorization Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<authReversal id="12345" customerId="Customer Id" reportGroup="Auth Reversals">
<cnpTxnId>12345678</cnpTxnId>
<amount>2999</amount>
</authReversal>
</cnpOnlineRequest>

3.3.2.2 Authorization Reversal Responses

The basic structure of an Authorization Reversal response is identical for Batch and Online responses.
<authReversalResponse id="Authorization Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
</authReversalResponse>

Example: Batch Authorization Reversal Response

This example shows a Batch Response containing three Authorization Reversal responses.
<cnpResponse version="12.10" xmlns="http://www.vantivcnp.com/schema" response="0"
message="ValidFormat" cnpSessionId="21500040809">
<batchResponse cnpBatchId="21500040908" merchantId="000902">
<authReversalResponse id="ID" reportGroup="core" customerId="Rev1">
<cnpTxnId>21200000002700</cnpTxnId>
<response>000</response>
<responseTime>2019-10-14T13:15:43</responseTime>
<message>Approved</message>
</authReversalResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

211
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<authReversalResponse id="ID" reportGroup="core" customerId="viRev2">

<cnpTxnId>21200000002809</cnpTxnId>
<response>000</response>
<responseTime>2019-10-14T13:15:43</responseTime>
<message>Approved</message>
</authReversalResponse>
<authReversalResponse id="ID" reportGroup="core" customerId="mcRev3">
<cnpTxnId>21200000002908</cnpTxnId>
<response>000</response>
<responseTime>2019-10-14T13:15:43</responseTime>
<message>Approved</message>
</authReversalResponse>
</batchResponse>
</cnpResponse>

Example: Online Authorization Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<authReversalResponse id="12345" customerId="Customer Id" reportGroup="Auth
Reversals">
<cnpTxnId>12345678</cnpTxnId>
<response>000</response>
<responseTime>2017-09-30T13:15:43</responseTime>
<message>Approved</message>
</authReversalResponse>
</cnpOnlineResponse>

3.3.3 Activate Transactions

The Activate transaction changes the status of a (Closed Loop) Gift Card from inactive to active with a
value as specified by the amount element. You can also use this transaction type to create a Virtual Gift
Card.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.3.1 Activate Request

You must structure an Activate request as shown in the following examples. The structure of the request
is identical for either an Online or a Batch submission.
<activate id="Activate Id" reportGroup="iQ Report Group" customerId="Customer Id">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

212
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderId>Order Id</orderId>
<amount>Activation Amount</amount>
<orderSource>Order Entry Source</orderSource>
[ <card> | <virtualGiftCard> ]
</activate>

Example: Activate Request - Gift Card

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<activate id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
</card>
</activate>
</cnpOnlineRequest>

Example: Activate Request - Virtual Gift Card

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<activate id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>ecommerce</orderSource>
<virtualGiftCard>
<accountNumberLength>16</accountNumberLength>
<giftCardBin>900000</giftCardBin>
</virtualGiftCard>
</activate>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

213
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.3.2 Activate Response

An Activate response has the following structure. The response message is identical for Online and Batch
transactions except Online includes the <postDate> element.
<activateResponse id="Activate Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<giftCardResponse>
<virtualGiftCardResponse>
</activateResponse>

Example: Activate Response - Gift Card

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<activateResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-01-25T15:13:43</responseTime>
<postDate>2017-01-25</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2016-11-25T15:13:38</txnTime>
<refCode>123456</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
</activateResponse>
</cnpOnlineResponse>

Example: Activate Response - Virtual Gift Card

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<activateResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

214
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<response>000</response>
<responseTime>2017-01-25T15:13:43</responseTime>
<postDate>2017-01-25</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-01-25T15:13:38</txnTime>
<refCode>123456</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
<virtualGiftCardResponse>
<accountNumber>9000000000000001</accountNumber>
<pin>1234</pin>
</virtualGiftCardResponse>
</activateResponse>
</cnpOnlineResponse>

3.3.4 Activate Reversal Transactions (Online Only)

The Activate Reversal transaction changes the status of a newly activated Gift Card from active to
inactive, thus reversing the operation of an Active transaction. The Activate Reversal references the
associated Activate transaction by means of the cnpTxnId element returned in the Activate response.
This transaction type is available only for Online transactions.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.4.1 Activate Reversal Request

You must structure an Activate Reversal request as shown in the following examples.
<activateReversal id="Activate Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id from Activate Response</cnpTxnId>
<card>
<virtualGiftCardBin>
<originalRefCode>Reference Code from Activate Response</originalRefCode>
<originalAmount>Amount from Activate Transaction</originalAmount>
<originalTxnTime>Transaction Time from Activate Response</originalTxnTime>
<originalSystemTraceId>Trace Id from Activate Response</originalSystemTraceId>
<originalSequenceNumber>Seq Num from Activate Rsp</originalSequenceNumber>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

215
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</activateReversal>

Example: Activate Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<activateReversal id="12345" customerId="Customer Id" reportGroup="Activate
Reversals">
<cnpTxnId>1234567890123456789</cnpTxnId>
<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</activateReversal>
</cnpOnlineRequest>

3.3.4.2 Activate Reversal Response

An Activate Reversal response has the following structure.

<activateReversalResponse id="Activate Reversal Id" reportGroup="iQ Report
Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</activateReversalResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

216
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Activate Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<activateReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</activateReversalResponse>
</cnpOnlineResponse>

3.3.5 Balance Inquiry Transactions

A Balance Inquiry transaction returns the available balance of a Gift Card.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.5.1 Balance Inquiry Request

You must structure an Balance Inquiry request as shown in the following examples. The structure of the
request is identical for either an Online or a Batch submission.
<balanceInquiry id="Balance Inquiry Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<orderSource>Order Entry Source</orderSource>
<card>
</balanceInquiry>

Example: Balance Inquiry Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

217
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<password>Password</password>
</authentication>
<balanceInquiry id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
<pin>1234</pin>
</card>
</balanceInquiry>
</cnpOnlineRequest>

3.3.5.2 Balance Inquiry Response

An Balance Inquiry response has the following structure. The response message is identical for Online
and Batch transactions except Online includes the <postDate> element.
<balanceInquiryResponse id="Balance Inquiry Id" reportGroup="iQ Report
Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<orderId>Order Id</orderId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<giftCardResponse>
</balanceInquiryResponse>

Example: Balance Inquiry Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<balanceInquiryResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<orderId>65347567</orderId>
<response>000</response>
<responseTime>2017-03-21T15:13:43</responseTime>
<postDate>2017-03-21</postDate>
<message>Approved</message>
<fraudResult>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

218
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cardValidationResult>N</cardValidationResult>
</fraudResult>
<giftCardResponse>
<availableBalance>2000</activateReversalResponse>
</cnpOnlineResponse>

3.3.6 Cancel Subscription Transactions

The Cancel Subscription transaction cancels the specified subscription, removing the transaction stream
managed by the Recurring Engine.

3.3.6.1 Cancel Subscription Request

You must structure an Cancel Subscription request as shown in the following examples. The structure of
the request is identical for either an Online or a Batch submission.
<cancelSubscription>
<subscriptionId>ID of Subscription to Cancel</subscriptionId>
</cancelSubscription>

Example: Cancel Subscription Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<cancelSubscription>
<subscriptionId>1234</subscriptionId>
</cancelSubscription>
</cnpOnlineRequest>

3.3.6.2 Cancel Subscription Response

A Cancel Subscription response has the following structure. The response message is identical for Online
and Batch transactions except Online includes the <postDate> element.
<cancelSubscriptionResponse>
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

219
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<responseTime>Date and Time in GMT</responseTime>

<subscriptionId>ID of Subscription Canceled</subscriptionId>
</cancelSubscriptionResponse>

Example: Cancel Subscription Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<cancelSubscriptionResponse>
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>
<message>Approved</message>
<responseTime>2017-04-11T14:48:46</responseTime>
<subscriptionId>123457</subscriptionId>
</cancelSubscriptionResponse>
</cnpOnlineResponse>

3.3.7 Capture Transactions

The Capture transaction transfers funds from the customer to the merchant. The Capture references the
associated Authorization by means of the cnpTxnId element returned in the Authorization response.

NOTE: To perform a capture on a Closed-loop Gift Card, submit a Gift Card Capture transaction,
not an Capture transaction. See Gift Card Capture Transactions on page 278 for additional
information.

You send a Capture after the order has been fulfilled. In some cases, it is not possible to fulfill a
customer’s entire order in one shipment (for example, if some items are back ordered, or some shipped
from an off-site DCS). In this situation, you can send a Partial Capture transaction by setting the partial
attribute to true. A Partial Capture contains only the data relevant to the items that were actually shipped,
enabling you to settle the funds related to those items.

NOTE: If you settle in a currency other than US or Canada, you cannot use partial captures.

3.3.7.1 Capture Request

You must structure a Capture request as shown in the following examples. The structure of the request is
identical for either an Online or a Batch submission.
<capture id="Capture Id" reportGroup="iQ Report Group" customerId="Customer Id"
partial="false">
<cnpTxnId>Transaction Id</cnpTxnId>
<amount>Authorization Amount</amount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

220
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<surchargeAmount>Surcharge Amount</surchargeAmount>
<enhancedData>
<processingInstructions>
<payPalOrderComplete>Set to true for final Capture</payPalOrderComplete>
<payPalNotes>Notes</paypalNotes>
<lodgingInfo>
<pin>Gift Card Pin Number</pin
</capture>

Example: Batch Capture Request - Full Capture

The following Capture example is for a full capture. Although the <capture> element includes an
<amount> child, it is not required for a full Capture. If you omit the <amount> child element, the capture
amount defaults to the full amount from the associated Authorization.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numAuths="0" authAmount="0" numCaptures="1"
captureAmount="55814" numCredits="0" creditAmount="0" numSales="0"
saleAmount="0" merchantId="100">
<capture id="AX54325432" reportGroup="RG12" partial="false">
<cnpTxnId>84568457</cnpTxnId>
<amount>55814</amount>
<enhancedData>
<customerReference>PO12346</customerReference>
<salesTax>1500</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>3714</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2011-09-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>500</taxAmount>
<taxRate>0.01667</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

221
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>1500</taxAmount>
<lineItemTotal>30000</lineItemTotal>
<lineItemTotalWithTax>31500</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>301</commodityCode>
<unitCost>300.00</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>500</taxAmount>
<taxRate>0.01667</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>20000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>301</commodityCode>
<unitCost>200.00</unitCost>
</lineItemData>
</enhancedData>
</capture>
</batchRequest>
</cnpRequest>

Example: Batch Capture Request - Partial Capture

A partial Capture has the partial attribute set to true and must include an amount child element.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

222
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<password>password</password>
</authentication>
<batchRequest id="01234567" numAuths="0" authAmount="0" numCaptures="1"
captureAmount="45814" numCredits="0" creditAmount="0" numSales="0"
saleAmount="0" merchantId="100">
<capture id="AX54325432" reportGroup="RG12" partial="true">
<cnpTxnId>84568457</cnpTxnId>
<amount>45814</amount>
<enhancedData>
<customerReference>PO12346</customerReference>
<salesTax>2100</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>3714</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-09-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>500</taxAmount>
<taxRate>0.01667</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>1500</taxAmount>
<lineItemTotal>30000</lineItemTotal>
<lineItemTotalWithTax>31500</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>301</commodityCode>
<unitCost>300.00</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>500</taxAmount>
<taxRate>0.01667</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

223
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>20000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>301</commodityCode>
<unitCost>200.00</unitCost>
</lineItemData>
</enhancedData>
</capture>
</batchRequest>
</cnpRequest>

Example: Online Capture Request - Full Capture

The following Capture example is for a full capture. Although the <capture> element includes an
<amount> child, it is not required for a full Capture. If you omit the <amount> child element, the capture
amount defaults to the full amount from the associated Authorization.
<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<capture id="2" reportGroup="ABC Division" customerId="038945" partial="false">
<cnpTxnId>13254123434</cnpTxnId>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2011-08-14</orderDate>
<detailTax>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

224
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>30000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>300.00</unitCost>
</lineItemData>
</enhancedData>
</capture>
</cnpOnlineRequest>

Example: Online Capture Request - Partial Capture

A partial Capture has the partial attribute set to true and must include an <amount> child element.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

225
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"

merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<capture id="2" reportGroup="ABC Division" customerId="038945" partial="true">
<cnpTxnId>13254123434</cnpTxnId>
<amount>100</amount>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2011-08-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

226
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>30000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>300.00</unitCost>
</lineItemData>
</enhancedData>
</capture>
</cnpOnlineRequest>

3.3.7.2 Capture Response

A Capture response has the following structure. The response message is identical for Online and Batch
transactions except Batch always includes the <orderId> element, while Online includes the
<postDate> element.
<captureResponse id="Authorization Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date Of Posting</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<accountUpdater>
</captureResponse>

Example: Batch Capture Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
cnpSessionId="987654321" response="0" message="Valid Format">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<captureResponse id="AX54321678" reportGroup="RG27">
<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<responseTime>2017-04-01T10:24:31</responseTime>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

227
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<message>Approved</message>
</captureResponse>
<captureResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2017-04-01T10:24:31</responseTime>
<message>message</message>
</captureResponse>
</batchResponse>
</cnpResponse>

Example: Online Capture Response

<cnpOnlineResponse version="12.12" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format" location="denver">
<captureResponse id="2" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>1100030204</cnpTxnId>
<response>000</response>
<responseTime>2020-01-11T14:48:48</responseTime>
<postDate>2020-01-11</postDate>
<message>Approved</message>
</captureResponse>
</cnpOnlineResponse>

3.3.8 Capture Given Auth Transactions

You typically use a Capture Given Auth transaction when the associated Authorization occurred outside
of the system (for example, if you received a telephone Authorization). Another possible use for a Capture
Given Auth transaction is if the Authorization transaction occurred within the system, but the
<cnpTxnId> is unknown by the submitting party (for example, if the Auth was submitted by a merchant,
but a fulfiller submits a Capture Given Auth).

3.3.8.1 Capture Given Auth Request

You must specify the Capture Given Auth request as follows. The structure of the request is identical for
either an Online or a Batch submission.
<captureGivenAuth id="Capture Given Auth Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<authInformation>
<amount>Authorization Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

228
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderSource>Order Entry Source</orderSource>

<billToAddress>
<shipToAddress>
[ <card> | <token> | <paypage> | <mpos>]
<customBilling>
<taxType>payment or fee</taxType>
<enhancedData>
<lodgingInfo>
<processingInstructions>
<pos>
<merchantData>
<debtRepayment>true or false</debtRepayment>
<processingType>processingType Enum</processingType>
<originalNetworkTransactionId>Network Txn Value</originalNetworkTransactionId>
<originalTransactionAmount>Amount from Orig Txn</originalTransactionAmount>
<merchantCategoryCode>MCC Value</merchantCategoryCode>
</captureGivenAuth>

Example: Batch Capture Given Auth Request

The following example shows a single Capture Given Auth request. The example uses the <card> child
element, but a tokenized merchant could use the <token> child element in its place.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests="1">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<batchRequest id="batchId" numCaptureGivenAuths="1"
captureGivenAuthAmount="10000" merchantId="100">
<captureGivenAuth id="AX54321678" reportGroup="RG27">
<orderId>orderId</orderId>
<authInformation>
<authDate>2016-09-21</authDate>
<authCode>123456</authCode>
</authInformation>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0910</expDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

229
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</card>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-09-21</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0055</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
</lineItemData>
</enhancedData>
</captureGivenAuth>
</batchRequest>
</cnpRequest>

Example: Online Capture Given Auth Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>userName</user>
<password>password</password>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

230
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</authentication>
<captureGivenAuth id="AX54321678" reportGroup="RG27">
<orderId>orderId</orderId>
<authInformation>
<authDate>2016-08-24</authDate>
<authCode>123456</authCode>
</authInformation>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0910</expDate>
</card>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<deliveryType>TBD</deliveryType>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-08-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

231
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
</lineItemData>
</enhancedData>
</captureGivenAuth>
</cnpOnlineRequest>

Example: Capture Given Auth Request using token Element

The example below uses the following token related elements (click name to jump to element definition):
token and cnpToken.
<captureGivenAuth id="99999" customerId="444" reportGroup="RG1">
<orderId>F12345</orderId>
<authInformation>
<authDate>2011-10-25</authDate>
<authCode>500005</authCode>
</authInformation>
<amount>15000</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>10 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
</billToAddress>
<token>
<cnpToken>1112000100010085</cnpToken>
<expDate>1112</expDate>
<cardValidationNum>987</cardValidationNum>
</token>
</captureGivenAuth>

3.3.8.2 Capture Given Auth Response

A Capture Given Auth response has the following structure. The response message is identical for Online
and Batch transactions except Online includes the <postDate> element.
<captureGivenAuthResponse id="Capture Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

232
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<responseTime>Date and Time in GMT</responseTime>

<postDate>Date of Posting</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<tokenResponse> (for Tokenized merchants submitting card data)
</captureGivenAuthResponse>

Example: Batch Capture Given Auth Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
cnpSessionId="987654321" response="0" message="Valid Format">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<captureGivenAuthResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2017-04-01T10:24:31</responseTime>
<message>Approved</message>
</captureGivenAuthResponse>
</batchResponse>
</cnpResponse>

Example: Online Capture Given Auth Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<captureGivenAuthResponse id="2" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>1100030204</cnpTxnId>
<response>000</response>
<responseTime>2017-04-11T14:48:48</responseTime>
<postDate>2017-04-11</postDate>
<message>Approved</message>
</captureGivenAuthResponse>
</cnpOnlineResponse>

Example: Capture Given Auth Response for Tokenized Merchant Sending Card Data
<captureGivenAuthResponse id="99999" reportGroup="RG1" customerId="444">
<cnpTxnId>21200000022005</cnpTxnId>
<response>000</response>
<responseTime>2017-04-25T04:00:00</responseTime>
<postDate>2017-04-26</postDate>
<message>Approved</message>
<tokenResponse>
<cnpToken>1111000100409510</cnpToken>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

233
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<tokenResponseCode>801</tokenResponseCode>
<tokenMessage>Account number was successfully registered</tokenMessage>
<type>VI</type>
<bin>432610</bin>
</tokenResponse>
</captureGivenAuthResponse>

3.3.9 Create Plan Transactions

The Create Plan transaction allows you to define several attributes of a recurring payment schedule.
Later, you can associate existing, active plans with subscriptions, which establishes a recurring payment
schedule managed by the Recurring Engine.

3.3.9.1 Create Plan Request

You must specify the Create Plan transaction as follows. The structure of the request is identical for either
an Online or a Batch submission.
<createPlan>
<planCode>Plan Reference Code</planCode>
<name>Name of Plan</name>
<description>Description of Plan</description>
<intervalType>The Type of Interval</intervalType>
<amount>Amount of Recurring Payment</amount>
<numberOfPayments>1 to 99</numberOfRemianingPayments>
<trialNumberOfIntervals>Number of Trial Intervals</trialNumberOfIntervals>
<trialIntervalType>Type of Trial Period Interval</trialIntervalType>
<active>true or false</active>
</createPlan>

Example: Online Create Plan Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<createPlan>
<planCode>Gold12</planCode>
<name>Gold_Monthly</name>
<description>Gold Level with Monthly Payments</description>
<intervalType>MONTHLY</intervalType>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

234
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<amount>5000</amount>
<numberOfPayments>4</numberOfPayments>
<trialNumberOfIntervals>1</trialNumberOfIntervals>
<trialIntervalType>MONTH</trialIntervalType>
<active>true</active>
</createPlan>
</cnpOnlineRequest>

3.3.9.2 Create Plan Response

The Create Plan response message is identical for Online and Batch transactions.
<createPlanResponse>
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Date and Time in GMT</responseTime>
<planCode>Plan Reference Code</subscriptionId>
</createPlanResponse>

Example: Online Create Plan Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<createPlanResponse>
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>
<message>Approved</message>
<responseTime>2016-07-11T14:48:46</responseTime>
<planCode>Gold12</planCode>
</createPlanResponse>
</cnpOnlineResponse>

3.3.10 Credit Transactions

The Credit transaction enables you to refund money to a customer, even if the original transaction
occurred outside of our system. You can submit refunds against any of the following payment
transactions:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

235
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: To perform a credit on a Closed-loop Gift Card, submit a Gift Card Credit transaction, not an
Credit transaction. See Gift Card Credit Transactions on page 280 for additional information.

• Capture Transactions
• Capture Given Auth Transactions
• Force Capture Transactions
• Sale Transactions
• External Sale or Capture Transactions

NOTE: If enabled for Auth for Refund, we automatically generate an Authorization before
processing the Credit. If the Issuing Bank declines the Authorization, you receive the decline
response code for the Authorization in the response message. If the Authorization passes, you
receive an Approved response code in the response message, but still must check the Declined
Transaction report to verify the Issuing Bank did not decline the Credit transaction.

NOTE: Although there are two different scenarios for Credit requests, there is only one scenario for
the Credit response.

3.3.10.1 Credit Request for a Worldpay Processed Transaction

You must specify the Credit request for a Worldpay processed transaction as follows. The structure of the
request is identical for either an Online or a Batch submission.
<credit id="Credit Id" reportGroup="iQ Report Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<amount>Authorization Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<customBilling>
<enhancedData>
<lodgingInfo>
<processingInstructions>
<actionReason>SUSPECT_FRAUD</actionReason>
</credit>

Example: Batch Credit Request for a Worldpay Processed Transaction

To request a Credit against a sale settled by us, you only need to specify the <cnpTxnId> element. The
application uses the <cnpTxnId> to look-up the Capture referenced and obtain all the necessary
information including the amount.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

236
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: Although it is not required, if you choose to include <amount> elements in your Credit
transaction, you must include the total amount in the creditAmount attribute of the
<batchrequest>. If you do not specify amounts, set the creditAmount attribute to 0.

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"

numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numAuths="0" authAmount="0" numCaptures="0"
captureAmount="0" numCredits="1" creditAmount="10000" numSales="0"
saleAmount="0" merchantId="100">
<credit id="AX54321678" reportGroup="RG27">
<cnpTxnId>84568456</cnpTxnId>
<amount>10000</amount>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>3017</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-09-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

237
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
</enhancedData>
</credit>
</batchRequest>
</cnpRequest>

Example: Online Credit Request for a Worldpay Processed Transaction

To request a Credit against a sale settled by us, you need only specify the <cnpTxnId> element. The
application uses the <cnpTxnId> to look up the Capture referenced and obtain all the necessary
information including the amount. The example below includes the optional <customBilling> and
<enhancedData> elements.
<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<credit id="2" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>13254123434</cnpTxnId>
<customBilling>
<phone>8888888888</phone>
<descriptor>descriptor</descriptor>
</customBilling>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

238
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderDate>2016-07-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>30000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>300.00</unitCost>
</lineItemData>
</enhancedData>
</credit>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

239
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.10.2 Credit Request for a Non-Worldpay Processed Transaction

You must specify the Credit request for a Non-Worldpay processed transaction as follows. The structure
of the request is identical for either an Online or a Batch submission.

NOTE: Although the schema shows <paypal> as an optional element for a Credit against a
non-Worldpay processed transaction, refunds of this type are not supported for PayPal. If you need
to refund non-Worldpay processed transactions and have not maintained a temporary relationship
with your former processor for this purpose, please ask your Relationship Manager for alternative
options.

<credit id="Credit Id" reportGroup="iQ Report Group" customerId="Customer Id">

<orderId>Order Id</orderId>
<amount>Authorization Amount</amount>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
[ <card> | <token> | <paypage> | <mpos> ]
<customBilling>
<taxType>payment or fee</taxType>
<enhancedData>
<lodgingInfo>
<processingInstructions>
<pos>
<merchantData>
<merchantCategoryCode>MCC Value</merchantCategoryCode>
</credit>

Example: Batch Credit Request for a Non-Worldpay Processed Transaction

If the sale occurred outside of our system, you must specify the following elements in your Credit request:
<orderId>, <amount>, and <card>, or <token> (<paypal> not supported for this
transaction type).
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numCredits="1" creditAmount="10000"
merchantId="100">
<credit id="AX54321678" reportGroup="RG27">
<orderId>12z58743y1</orderId>
<amount>10000</amount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

240
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<card>
<type>MC</type>
<number>5186005800001012</number>
<expDate>1110</expDate>
</card>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-09-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

241
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
</lineItemData>
</enhancedData>
</credit>
</batchRequest>
</cnpRequest>

Example: Online Credit Request for a Non-Worldpay Processed Transaction

If the sale occurred outside of our system, you must specify the following elements in your Credit request:
<orderId>, <amount>, and <card>, or <token> (<paypal> not supported for this
transaction type).
<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<credit id="2" reportGroup="ABC Division" customerId="038945">
<orderId>56789</orderId>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>Mike J. Hammer</name>
<addressLine1>Two Main Street</addressLine1>
<addressLine2>Apartment 222</addressLine2>
<addressLine3></addressLine3>
<city>Riverside</city>
<state>RI</state>
<zip>02915</zip>
<country>US</country>
<email>[email protected]</email>
<phone>5555555555</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0907</expDate>
</card>
<customBilling>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

242
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<phone>5555555555</phone>
<descriptor>descriptor</descriptor>
</customBilling>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2011-08-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>30000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

243
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<unitCost>300.00</unitCost>
</lineItemData>
</enhancedData>
</credit>
</cnpOnlineRequest>

3.3.10.3 Credit Response

The Credit response message is identical for Online and Batch transactions except Online includes the
postDate element.

NOTE: Although there are two different scenarios for Credit requests, there is only one scenario for
the Credit response.

<creditResponse id="Credit Id" reportGroup="iQ Report Group" customerId="Customer Id">

<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date of Posting</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<tokenResponse> (for Tokenized merchants submitting card data)
</creditResponse>

Example: Credit Response

The example below illustrates a Batch Credit response. A response for an Online transaction uses a
cnpOnlineResponse element as the parent.
<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
cnpSessionId="987654321" response="0" message="Valid Format">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<creditResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2017-04-01T10:24:31</responseTime>
<message>Approved</message>
</creditResponse>
</batchResponse>
</cnpResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

244
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Credit Response for a Tokenized Merchant Sending Card Data

When a tokenized merchant submits card data in the Credit request, the response includes the
tokenResponse element. The example below is a response for an Online request
(<cnpOnlineResponse> element not shown), so it includes the <postDate> element.
<creditResponse id="99999" reportGroup="RG1" customerId="444">
<cnpTxnId>21200000473208</cnpTxnId>
<response>000</response>
<responseTime>2017-04-19T19:29:45</responseTime>
<postDate>2017-04-19</postDate>
<message>Approved</message>
<tokenResponse>
<cnpToken>1111102200202001</cnpToken>
<tokenResponseCode>801</tokenResponseCode>
<tokenMessage>Account number was successfully registered</tokenMessage>
<type>VI</type>
<bin>402410</bin>
</tokenResponse>
</creditResponse>

3.3.11 Deactivate Transactions

The Deactivate transaction changes the status of a (Closed Loop) Gift Card from active to inactive.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.11.1 Deactivate Request

You must structure a Deactivate request as shown in the following examples. The structure of the request
is identical for either an Online or a Batch submission.
<deactivate id="Activate Id" reportGroup="iQ Report Group" customerId="Customer Id">
<orderId>Order Id</orderId>
<orderSource>Order Entry Source</orderSource>
<card>
</deactivate>

Example: Online Deactivate Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

245
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<user>User Name</user>
<password>Password</password>
</authentication>
<deactivate id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
<pin>1234</pin>
</card>
</deactvate>
</cnpOnlineRequest>

3.3.11.2 Deactivate Response

A Deactivate response has the following structure. The response message is identical for Online and
Batch transactions except Online includes the <postDate> element.
<deactivateResponse id="Deactivate Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<approvedAmount>5000</approvedAmount>
<giftCardResponse>
</deactivateResponse>

Example: Online Deactivate Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<deactivateResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2016-07-25T15:13:43</responseTime>
<postDate>2016-07-25</postDate>
<message>Approved</message>
<approvedAmount>5000</approvedAmount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

246
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<giftCardResponse>
<availableBalance>0</availableBalance>
<beginningBalance>5000</beginningBalance>
<endingBalance>0</endingBalance>
</giftCardResponse>
</deactivateResponse>
</cnpOnlineResponse>

3.3.12 Deactivate Reversal Transactions (Online Only)

The Deactivate Reversal transaction changes the status of a newly deactivated Gift Card from inactive to
active, thus reversing the operation of an Deactivate transaction. The Deactivate Reversal references the
associated Deactivate transaction by means of the cnpTxnId element returned in the Deactivate
response. This transaction type is available only for Online transactions.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.12.1 Deactivate Reversal Request

You must structure an Deactivate Reversal request as shown in the following examples.
<deactivateReversal id="Deactivate Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id from Load Response</cnpTxnId>
<card>
<originalRefCode>Reference Code from Deactivate Response</originalRefCode>
<originalAmount>Amount from Deactivate Transaction</originalAmount>
<originalTxnTime>Transaction Time from Deactivate Response</originalTxnTime>
<originalSystemTraceId>Trace Id from Deactivate Resp</originalSystemTraceId>
<originalSequenceNumber>Seq Num from Deactivate Resp</originalSequenceNumber>
</deactivateReversal>

Example: Deactivate Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<deactivateReversal id="12345" customerId="Customer Id" reportGroup="Deactivate
Reversals">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

247
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>1234567890123456789</cnpTxnId>
<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</deactivateReversal>
</cnpOnlineRequest>

3.3.12.2 Deactivate Reversal Response

An Deactivate Reversal response has the following structure.

<deactivateReversalResponse id="Deactivate Reversal Id" reportGroup="iQ Report
Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</deactivateReversalResponse>

Example: Online Deactivate Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<deactivateReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

248
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
</deactivateReversalResponse>
</cnpOnlineResponse>

3.3.13 Deposit Reversal Transactions (Online Only)

The Deposit Reversal transaction is a Gift Card transaction that reverses the deposit initiated by either a
Capture or Sale transaction. The Deposit Reversal references the associated Capture/Sale transaction by
means of the cnpTxnId element returned in the Capture/Sale response. This transaction type is
available only for Online transactions.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.13.1 Deposit Reversal Request

You must structure an Deposit Reversal request as shown in the following examples.
<depositReversal id="Deposit Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id from Load Response</cnpTxnId>
<card>
<originalRefCode>Reference Code from Gift Card Capture Resp</originalRefCode>
<originalAmount>Amount from Gift Card Capture Resp</originalAmount>
<originalTxnTime>Transaction Time from GC Capture Response</originalTxnTime>
<originalSystemTraceId>Trace Id from GC Capture Resp</originalSystemTraceId>
<originalSequenceNumber>Seq Num from GC Capture Resp</originalSequenceNumber>
</depositReversal>

Example: Deposit Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<depositReversal id="12345" customerId="Customer Id" reportGroup="Deposit
Reversals">
<cnpTxnId>1234567890123456789</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

249
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</depositReversal>
</cnpOnlineRequest>

3.3.13.2 Deposit Reversal Response

An Deposit Reversal response has the following structure.

<depositReversalResponse id="Deactivate Reversal Id" reportGroup="iQ Report
Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</depositReversalResponse>

Example: Online Deposit Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<depositReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

250
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<availableBalance>5000</availableBalance>
</giftCardResponse>
</depositReversalResponse>
</cnpOnlineResponse>

3.3.14 eCheck Credit Transactions

The eCheck Credit transaction enables you to refund a previous eCheck Sale. Merchants can submit an
eCheck Credit transaction for a sale regardless or whether the original transaction was settled by our
system, although the requests are structured differently. This section contains the following:
• eCheck Credit Request Against a Worldpay Transaction
• eCheck Credit Request for a Non-Worldpay Processed Sale
• eCheck Credit Response

NOTE: Although there are two different scenarios for eCheck Credit requests, the response
message uses the same structure.

3.3.14.1 eCheck Credit Request Against a Worldpay Transaction

To request an eCheck Credit against an eCheck Sale that had been settled by us, you only need to
specify the <cnpTxnId> element. When you specify this element, the application uses the <cnpTxnId>
to look up the referenced echeckSale transaction and obtain the necessary information. In this case, the
<amount> element is optional, but should be included if the credit amount is less than the captured
amount. If you do not include the <amount> element, the system assumes the credit to be for the total
amount of the referenced transaction.
When requesting a echeckCredit against an echeckSale that occurred within our system, specify the
Credit request as follows:
<echeckCredit id="Credit Id" reportGroup="iQ Report Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<amount>Credit Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<customBilling> (Do not use)
<customIdentifier>
</echeckCredit>

Example: eCheck Credit Request

The eCheck Credit batch request shown below contains three <echeckCredit> elements. The first two
use a Transaction Id as a reference. The third, which you would use for a sale occurring outside of our
system, uses the <orderId>, <amount>, <billToAddress>, and <echeck> elements to provide the
required information.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

251
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="xmlbat01" numEcheckCredit="3" echeckCreditAmount="12100"
merchantId="000053">
<echeckCredit id="credit1" reportGroup="new53" customerId="53">
<cnpTxnId>4455667788</cnpTxnId>
<amount>1000</amount>
</echeckCredit>
<echeckCredit reportGroup="new53">
<cnpTxnId>4455667789</cnpTxnId>
<amount>1100</amount>
</echeckCredit>
<echeckCredit reportGroup="new53">
<orderId>12z58743y1</orderId>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<echeck>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
</echeckCredit>
</batchRequest>
</cnpRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

252
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.14.2 eCheck Credit Request for a Non-Worldpay Processed Sale

If the original eCheck Sale transaction was not processed via our system, or the if the <cnpTxnId> for
the original eCheck Sale transaction is not available, specify eCheck Credit request as follows:
<echeckCredit id="eCheckCredit Id" reportGroup="iQ Report Group" customerId="Customer
Id">
<orderId>Order Id</orderId>
<amount>Credit Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
<echeck> or <echeckToken>
<customBilling> (Do not use)
<merchantData>
</echeckCredit>
The third transaction shown in the eCheck Credit Request example on page 251 shows an example of a
Credit request against a non-Worldpay processed transaction.

3.3.14.3 eCheck Credit Response

The eCheck Credit message is identical for either type of eCheck Credit request. The
<accountUpdater> element is included only if you submit account information in the request
transaction for which a NOC exists. In this case the system automatically updates the information sent to
the ACH network and includes the change information in the response.
The eCheck Credit response has the following structure:
<echeckCreditResponse id="eCheck Credit Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
<postDate>Date of Posting</postDate> (Online Only)
<accountUpdater>Account Change Info</accountUpdater>
<tokenResponse> (for Tokenized merchants submitting account data)
</echeckCreditResponse>

Example: eCheck Credit Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

253
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">

<echeckCreditResponse id="AX54321678" reportGroup="RG27" customerId="53">
<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<responseTime>2017-04-01T10:24:31</responseTime>
<message>Approved</message>
</echeckCreditResponse>
</batchResponse>
</cnpResponse>

3.3.15 eCheck Prenotification Credit Transactions (Batch Only)

You use this non-monetary transaction to verify the consumer’s account information prior to submitting an
eCheck Credit transaction (also see eCheck Prenotification on page 49). This transaction type is only
supported for US transactions.

3.3.15.1 eCheck Prenotification Credit Request

You must specify the eCheck Prenotification Credit request using the following format:
<echeckPreNoteCredit id="eCheck PreNote Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
<echeck>
<merchantData>
</echeckPreNoteCredit>

Example: eCheck Prenotification Credit Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="654321" numEcheckPreNoteCredit="1" merchantId="100">
<echeckPreNoteCredit id="AX54321678" reportGroup="RG27" customerId="53">
<orderId>12z58743y1</orderId>
<orderSource>telephone</orderSource>
<billToAddress>
<firstName>John</firstName>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

254
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<lastName>Doe</lastName>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<echeck>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
</echeckPreNoteCredit>
</batchRequest>
</cnpRequest>

3.3.15.2 eCheck Prenotification Credit Response

The eCheck Prenotification Credit response has the following structure:

<echeckPreNoteCreditResponse id="eCheckSale Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<orderId>Order Id</orderId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
</echeckPreNoteCreditResponse>

Example: eCheck Prenotification Credit Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<echeckPreNoteCreditResponse id="AX54321678" reportGroup="RG27"
customerId="53">
<cnpTxnId>84568456</cnpTxnId>
<orderId>12z58743y1</orderId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

255
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<response>000</response>
<responseTime>2017-03-01T10:24:31</responseTime>
<message>Approved</message>
</echeckPreNoteCreditResponse>
<echeckPreNoteCreditResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<orderId>12z58743y7</orderId>
<response>000</response>
<responseTime>2017-03-01T10:24:31</responseTime>
<message>Approved</message>
</echeckPreNoteCreditResponse>
</batchResponse>
</cnpResponse>

3.3.16 eCheck Prenotification Sale Transactions (Batch Only)

You use this non-monetary transaction to verify the consumer’s account information prior to submitting an
eCheck Sale transaction (also see eCheck Prenotification on page 49). This transaction type is only
supported for US transactions.

3.3.16.1 eCheck Prenotification Sale Request

You must specify the eCheck Prenotification Credit request using the following format:
<echeckPreNoteSale id="eCheck PreNote Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
<echeck>
<merchantData>
</echeckPreNotesale>

Example: eCheck Prenotification Sale Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="654321" numEcheckPreNoteSale="1" merchantId="100">
<echeckPreNoteSale id="AX54321678" reportGroup="RG27" customerId="53">
<orderId>12z58743y1</orderId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

256
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderSource>telephone</orderSource>
<billToAddress>
<firstName>John</firstName>
<lastName>Doe</lastName>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<echeck>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
</echeckPreNoteSale>
</batchRequest>
</cnpRequest>

3.3.16.2 eCheck Prenotification Sale Response

The eCheck Prenotification Sale response has the following structure:

<echeckPreNoteSaleResponse id="eCheckSale Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<orderId>Order Id</orderId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
</echeckPreNoteSaleResponse>

Example: eCheck Prenotification Sale Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

257
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<echeckPreNoteSaleResponse id="AX54321678" reportGroup="RG27" customerId="53">

<cnpTxnId>84568456</cnpTxnId>
<orderId>12z58743y1</orderId>
<response>000</response>
<responseTime>2017-03-01T10:24:31</responseTime>
<message>Approved</message>
</echeckPreNoteCreditResponse>
<echeckPreNoteCreditResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<orderId>12z58743y7</orderId>
<response>000</response>
<responseTime>2017-03-01T10:24:31</responseTime>
<message>Approved</message>
</echeckPreNoteSaleResponse>
</batchResponse>
</cnpResponse>

3.3.17 eCheck Redeposit Transactions

You use this transaction type to manually attempt redeposits of eChecks returned for either Insufficient
Funds or Uncollected Funds. You can use this element in either Batch or Online transactions.

NOTE: Do not use this transaction type if you are enabled for the Auto Redeposit feature. If you are
enabled for the Auto Redeposit feature, the system will reject any echeckRedeposit transaction
you submit.

3.3.17.1 eCheck Redeposit Request

You must specify the eCheck Redeposit request using the following format:
<echeckRedeposit id="eCheck Redeposit Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<echeck> or <echeckToken>
<merchantData>
<customIdentifier>
</echeckredeposit>

NOTE: If you include the echeck element, the values submitted for accType, accNum, and
routingNum children must match those submitted in the original echeckSale transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

258
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Online eCheck Redeposit Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="81603">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<echeckRedeposit reportGroup="001603">
<cnpTxnId>345454444</cnpTxnId>
<echeck>
<accType>Checking</accType>
<accNum>1099999903</accNum>
<routingNum>114567895</routingNum>
</echeck>
<merchantData>
<campaign>New Marketing Campaign</campaign>
</merchantData>
</echeckRedeposit>
</cnpOnlineRequest>

Example: Batch eCheck Redeposit Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests="1">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<batchRequest id="uniqueId" numEcheckRedeposit="4" merchantId="1603">
<echeckRedeposit reportGroup="001603">
<cnpTxnId>3456456444</cnpTxnId>
<merchantdata>
<affiliate>ABC Marketing</affiliate>
</merchantdata>
</echeckRedeposit>
<echeckRedeposit reportGroup="001603">
<cnpTxnId>3456456449</cnpTxnId>
<echeck>
<accType>Checking</accType>
<accNum>1099999903</accNum>
<routingNum>114567895</routingNum>
</echeck>
<merchantdata>
<affiliate>ABC Marketing</affiliate>
</merchantdata>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

259
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</echeckRedeposit>
<echeckRedeposit reportGroup="001603">
<cnpTxnId>3456557123</cnpTxnId>
<echeck>
<accType>Savings</accType>
<accNum>10999999444</accNum>
<routingNum>114567895</routingNum>
</echeck>
<merchantdata>
<affiliate>ABC Marketing</affiliate>
</merchantdata>
</echeckRedeposit>
<echeckRedeposit reportGroup="001603">
<cnpTxnId>123456789</cnpTxnId>
</echeckRedeposit>
</batchRequest>
</cnpRequest>

3.3.17.2 eCheck Redeposit Response

The eCheck Redeposit response indicates that we have received your eCheck Redeposit request. This
does not indicate when funds will be transferred. The <accountUpdater> element is included only if the
account information submitted in the request transaction has changed (NOC exists). In this case the
system automatically updates the information sent to the ACH network and includes the change
information in the response.
The eCheck Sale response has the following structure:
<echeckRedepositResponse id="eCheckRedeposit Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
<postDate>Date of Posting</postDate> (Online Only)
<accountUpdater>Account Change Info</accountUpdater>
</echeckRedepositResponse>

Example: Batch eCheck Redeposit Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<echeckRedepositResponse id="AX54321678" reportGroup="RG27" customerId="53">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

260
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<responseTime>2017-06-01T10:24:31</responseTime>
<message>Approved</message>
</echeckRedepositResponse>
<echeckRedepositResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2017-06-01T10:24:31</responseTime>
<message>Approved</message>
<accountUpdater>
<originalAccountInfo>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
</originalAccountInfo>
<newAccountInfo>
<accType>Checking</accType>
<accNum>5499576040500006</accNum>
<routingNum>000010102</routingNum>
</newAccountInfo>
</accountUpdater>
</echeckRedepositResponse>
</batchResponse>
</cnpResponse>

3.3.18 eCheck Sale Transactions

You use the eCheck Sale transaction to capture funds from a customer paying via electronic checks. It is
the Direct Debit equivalent of a Capture transaction. Setting the <verify> element to true triggers an
eCheck Verification operation prior to the capture. If the verification fails, the system does not process the
capture operation.

NOTE: To perform a verification you must include the following optional children of the
billToAddress element in your request: firstName, lastName, companyName (if accType =
Corporate or Corp Savings), address1 (address 2 and 3 if needed), city, state, zip, and
phone.
The value for the orderSource element must be one of the following: telephone, ecommerce, or
recurringtel.

3.3.18.1 eCheck Sale Request

You must specify the eCheck Sale request using the following format:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

261
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<echeckSale id="eCheckSale Id" reportGroup="iQ Report Group" customerId="Customer Id">

<orderId>Order Id</orderId>
<verify>true or false</verify>
<amount>Authorization Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
<shipToAddress>
<echeck> or <echeckToken>
<customBilling> (Do not use)
<merchantData>
<customIdentifier>
</echeckSale>

Example: Batch eCheck Sale Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="654321" numEcheckSales="1" echeckSalesAmount="10000"
merchantId="100">
<echeckSale id="AX54321678" reportGroup="RG27" customerId="53">
<orderId>12z58743y1</orderId>
<verify>true</verify>
<amount>10000</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<firstName>John</firstName>
<lastName>Doe</lastName>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<echeck>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

262
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
</echeckSale>
</batchRequest>
</cnpRequest>

3.3.18.2 eCheck Sale Response

The eCheck Sale response indicates that we have received your eCheck Sale request. This does not
indicate when funds will be transferred. The <accountUpdater> element is included only if the account
information submitted in the request transaction has changed (NOC exists). In this case the system
automatically updates the information sent to the ACH network and includes the change information in the
response.

NOTE: The schema for echeckSalesResponse includes a verificationCode child element.

This element is not used at this time.

The eCheck Sale response has the following structure:

<echeckSalesResponse id="eCheckSale Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
<postDate>Date of Posting</postDate> (Online Only)
<accountUpdater>Account Change Info</accountUpdater>
<tokenResponse> (for Tokenized merchants submitting account data)
</echeckSaleResponse>

Example: Batch eCheck Sale Response

The response example below includes the accountUpdater element, which indicates that there is a
NOC against the account and provides the new account information. If the request used a token, the
accountUpdater element would have children providing the original and new token information.
<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<echeckSalesResponse id="AX54321678" reportGroup="RG27" customerId="53">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

263
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
</echeckSalesResponse>
<echeckSalesResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
<accountUpdater>
<originalAccountInfo>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
</originalAccountInfo>
<newAccountInfo>
<accType>Checking</accType>
<accNum>5499576040500006</accNum>
<routingNum>000010102</routingNum>
</newAccountInfo>
</accountUpdater>
</echeckSalesResponse>
</batchResponse>
</cnpResponse>

3.3.19 eCheck Verification Transactions

You use an eCheck Verification transaction to initiate a comparison to a database containing information
about checking accounts. The database may include information as to whether the account has been
closed, as well as whether there is a history of undesirable behavior associated with the account/account
holder. This transaction type is only supported for US transactions.

NOTE: While eCheck Verification is a valuable tool that you can use to reduce possible fraud and
loss, unlike a credit card authorization, it does not check for the availability of funds, nor does it
place a hold on any funds.

3.3.19.1 eCheck Verification Request

You must specify the eCheck Verification request using the following format:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

264
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

IMPORTANT: For an eCheckVerification transaction, you must submit the firstName and
lastName elements instead of the name element (middleInitial is optional). For a corporate
account you must include the companyName element in addition to the firstName and lastName
elements. In both cases, you also must include the address, city, state, zip and phone
information.
For a corporate account, if you do not have the name of the check issuer, you can use a value of
“unavailable” for the firstName and lastName elements.

<echeckVerification id="echeckVerification Id" reportGroup="iQ Report Group"

customerId="Customer Id">
<orderId>Order Id</orderId>
<amount>Authorization Amount</amount>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
<echeck> or <echeckToken>
<merchantData>
</echeckVerification>

Example: eCheck Verification Request - Personal Checking

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="654321" numEcheckVerification="1"
echeckVerificationAmount="10000" merchantId="100">
<echeckVerification id="AX54321678" reportGroup="RG27" customerId="53">
<orderId>12z58743y1</orderId>
<amount>10000</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<firstName>John</firstName>
<lastName>Doe</lastName>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

265
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</billToAddress>
<echeck>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
<merchantData>
<campaign>New Campaign</campaign>
</merchantData>
</echeckVerification>
</batchRequest>
</cnpRequest>

Example: eCheck Verification Request - Corporate Account

NOTE: If you do not have the name of the check issuer, you can use a value of “unavailable”
for the firstName and lastName elements.

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"

numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="654321" numEcheckVerification="1"
echeckVerificationAmount="10000" merchantId="100">
<echeckVerification id="AX54321678" reportGroup="RG27" customerId="53">
<orderId>12z58743y1</orderId>
<amount>10000</amount>
<orderSource>telephone</orderSource>
<billToAddress>
<firstName>Paul</firstName>
<lastName>Jones</lastName>
<companyName>Widget Company</companyName>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

266
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</billToAddress>
<echeck>
<accType>Corporate</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
<checkNum>1104</checkNum>
</echeck>
</echeckVerification>
</batchRequest>
</cnpRequest>8.6

3.3.19.2 eCheck Verification Response

The <accountUpdater> element is included only if the account information submitted in the request
transaction has changed (NOC exists). In this case the system automatically updates the information sent
to the ACH network and includes the change information in the response.
The eCheck Verification response has the following structure:
<echeckVerificationResponse id="echeckVerification Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
<postDate>Date of Posting</postDate> (Online Only)
<tokenResponse> (for Tokenized merchants submitting account data)
<accountUpdater>Account Change Info</accountUpdater>
</echeckSaleResponse>

Example: eCheck Verification Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<echeckVerificationResponse id="AX54321678" reportGroup="RG27" customerId="53">
<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
</echeckVerificationResponse>
<echeckVerificationResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

267
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<response>000</response>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
<accountUpdater>
<originalAccountInfo>
<accType>Checking</accType>
<accNum>5186005800001012</accNum>
<routingNum>000010101</routingNum>
</originalAccountInfo>
<newAccountInfo>
<accType>Checking</accType>
<accNum>5499576040500006</accNum>
<routingNum>000010102</routingNum>
</newAccountInfo>
</accountUpdater>
</echeckVerificationResponse>
</batchResponse>
</cnpResponse>

3.3.20 eCheck Void Transactions (Online Only)

You use an eCheck Void transaction to either halt automatic redeposit attempts of eChecks returned for
either Insufficient Funds or Uncollected Funds, or cancel an eCheck Sale transaction, as long as the
transaction has not yet settled. This also applies to merchant initiated redeposits. You can use this
element only in Online transactions.

3.3.20.1 eCheck Void Request

The eCheck Void request references the <cnpTxnId> of the previously approved transaction. You must
structure an eCheck Void request as follows.
<echeckVoid id = "echeckVoid Id" reportGroup="iQ Report Group">
<cnpTxnId>Transaction Id</cnpTxnId>
</echeckVoid>

Example: eCheck Void Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="81601">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<echeckVoid id="101" reportGroup="001601">
<cnpTxnId>345454444</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

268
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</echeckVoid>
</cnpOnlineRequest>

3.3.20.2 eCheck Void Response

The eCheck Void response has the following structure.

<echeckVoidResponse id="eCheck Void Id" reportGroup="iQ Report Group" numDeposits=>"1"
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date of Posting</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
</echeckVoidResponse>

Example: Online eCheck Void Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<echeckVoidResponse id="101" reportGroup="001601">
<cnpTxnId>21200000026600</cnpTxnId>
<response>000</response>
<responseTime>2017-06-17T21:20:50</responseTime>
<message>Approved</message>
<postDate>2017-06-17</postDate>
</echeckVoidResponse>
</cnpOnlineResponse>

3.3.21 Force Capture Transactions

A Force Capture transaction is a Capture transaction used when you do not have a valid Authorization for
the order, but have fulfilled the order and wish to transfer funds.

CAUTION: Merchants must be authorized by Worldpay before submitting transactions of this type.
In some instances, using a Force Capture transaction can lead to chargebacks and fines.

3.3.21.1 Force Capture Request

You must specify the Force Capture request as follows. The structure of the request is identical for either
an Online or a Batch submission.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

269
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<forceCapture id="Id" reportGroup="iQ Report Group" customerId="Customer Id">

<orderId>Order Id</orderId>
<amount>Force Capture Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>
<orderSource>Order Entry Source</orderSource>
<billToAddress>
[ <card | token> | <paypage> | <mpos>]
<customBilling>
<taxType>payment or fee</taxType>
<enhancedData>
<lodgingInfo>
<processingInstructions>
<pos>
<merchantData>
<debtRepayment>true or false</debtRepayment>
<processingType>processingType Enum</processingType>
<merchantCategoryCode>MCC Value</merchantCategoryCode>
</forceCapture>

Example: Batch Force Capture Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numForceCaptures="1" forceCaptureAmount="10000"
merchantId="100">
<forceCapture id="AX54321678" reportGroup="RG27" customerId="038945">
<orderId>orderId</orderId>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0910</expDate>
</card>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

270
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-09-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
</enhancedData>
</forceCapture>
</batchRequest>
</cnpRequest>

Example: Online Force Capture Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="123">
<authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

271
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<user>userName</user>
<password>password</password>
</authentication>
<forceCapture id="AX54321678" reportGroup="RG27" customerId="038945">
<orderId>orderId</orderId>
<amount>10000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>0907</expDate>
</card>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-08-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
</lineItemData>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

272
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</enhancedData>
</forceCapture>
</cnpOnlineRequest>

3.3.21.2 Force Capture Response

The Force Capture response message is identical for Online and Batch transactions, except Online
includes the <postDate> element. The Force Capture response has the following structure:
<forceCaptureResponse id="Capture Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date of Posting</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<tokenResponse> (for Tokenized merchants submitting card data)
<accountUpdater>
</forceCaptureResponse>

Example: Batch Force Capture Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
cnpSessionId="987654321" response="0" message="Valid Format">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<forceCaptureResponse id="AX54325432" reportGroup="RG12" customerId="038945">
<cnpTxnId>84568457</cnpTxnId>
<response>000</response>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
</forceCaptureResponse>
</batchResponse>
</cnpResponse>

Example: Online Force Capture Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<forceCaptureResponse id="2" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>1100030204</cnpTxnId>
<response>000</response>
<responseTime>2016-07-11T14:48:48</responseTime>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

273
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<postDate>2016-07-11</postDate>
<message>Approved</message>
</forceCaptureResponse>
</cnpOnlineResponse>

Example: Force Capture Response for Tokenized Merchant Sending Card Data
A tokenized merchant that includes card information in the request receives a response message that
includes the token element. The example below is an Online response.
<forceCaptureResponse id="99999" reportGroup="RG1" customerId="444">
<cnpTxnId>21200000039504</cnpTxnId>
<response>000</response>
<responseTime>2016-10-20T18:25:38</responseTime>
<postDate>2016-10-20</postDate>
<message>Approved</message>
<tokenResponse>
<cnpToken>111310880008000</cnpToken>
<tokenResponseCode>801</tokenResponseCode>
<tokenMessage>Account number was successfully registered</tokenMessage>
<type>AX</type>
<bin></bin>
</tokenResponse>
</forceCaptureResponse>

3.3.22 Fraud Check Transaction

If you wish to retrieve the Advanced Fraud results without introducing a Authorization or Sale
transactions, use a Fraud Check transaction, as shown in the example below. Fraud Check transactions
are only supported as Online transactions.

3.3.22.1 Fraud Check Request

You must specify the Fraud Check request as follows.

<fraudCheck id="Fraud Check Id" reportGroup="iQ Report Group">
<advancedFraudChecks>
<billToAddress>
<shipToAddress>
<amount>Transaction Amount</amount>
<eventType>eventType Enum</eventType>
<accountLogin>Account Login Name</accountLogin>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

274
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<accountPasshash>Account Password Hash in Hex</accountPasshash>

</fraudCheck>

Example: Fraud Check Request

<cnpOnlineRequest version="12.5" xmlns="http://www.vantivcnp.com/schema"
merchantId="81601">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<fraudCheck id="002" reportGroup="001601">
<advancedFraudChecks>
<webSessionId>ASDFG-AXXXXAB999</webSessionId>
<customAttribute1>Attribute passed to ThreatMetrix</customAttribute1>
<customAttribute2>Attribute passed to ThreatMetrix</customAttribute2>
<customAttribute3>Attribute passed to ThreatMetrix</customAttribute3>
<customAttribute4>Attribute passed to ThreatMetrix</customAttribute4>
<customAttribute5>Attribute passed to ThreatMetrix</customAttribute5>
</advancedFraudChecks>
<billToAddress>
<name>John Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</billToAddress>
<shipToAddress>
<name>Jane Doe</name>
<addressLine1>15 Main Street</addressLine1>
<city>San Jose</city>
<state>CA</state>
<zip>95032-1234</zip>
<country>USA</country>
<phone>9782750000</phone>
<email>[email protected]</email>
</shipToAddress>
<amount>10015</amount>
<eventType>payment</eventType>
<accountLogin>jdoe123</accountLogin>
<accountPasshash>4241B68FBC12414a94...DF141761614813</accountPasshash>
</fraudCheck>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

275
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</cnpOnlineRequest>

3.3.22.2 Fraud Check Response

A Fraud Check response has the following structure.

<fraudCheckResponse id="Fraud Check Id" reportGroup="iQ Report Group">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Date and Time in GMT</responseTime>
<advancedFraudResults>
</fraudCheckResponse>

Example: Fraud Check Response

<cnpOnlineResponse version="12.7" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<fraudCheckResponse id="002" reportGroup="001601">
<cnpTxnId>82823534116454639</cnpTxnId>
<response>000</response>
<message>Approved</message>
<responseTime>2018-11-08T21:36:50</responseTime>
<advancedFraudResults>
<deviceReviewStatus>pass</deviceReviewStatus>
<deviceReputationScore>50</deviceReputationScore>
<triggeredRule>FlashImagesCookiesDisabled</triggeredRule>
</advancedFraudResults>
</fraudCheckResponse>
</cnpOnlineResponse>

3.3.23 Gift Card Auth Reversal Transactions

The Gift Card Auth Reversal transaction allows you to reverse an authorization against a closed-loop gift
card; thereby, removing the funds hold established by the authorization.

3.3.23.1 Gift Card Auth Reversal Request

You must specify the Gift Card Auth Reversal request as follows. The structure of the request is identical
for either an Online or a Batch submission.
<giftCardAuthReversal id="Id" reportGroup="iQ Report Group" customerId="Customer Id">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

276
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>Transaction Id from Auth Response</cnpTxnId>

<card>
<originalRefCode>Auth Code from Auth Response</originalRefCode>
<originalAmount>Amount from Auth Response</originalAmount>
<originalTxnTime>txnTime from Auth Response</originalTxnTime>
<originalSystemTraceId>systemTraceId from Auth Rsp</originalSystemTraceId>
<originalSequenceNumber>sequenceNumber from Auth Rsp</originalSequenceNumber>
</giftCardAuthReversal>

Example: Online Gift Card Auth Reversal

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<giftCardAuthReversal id="834262" reportGroup="ABC Division"
customerId="038945">
<cnpTxnId>82823534116454002</cnpTxnId>
<card>
<type>GC</type>
<number>9000000000000001</number>
<PIN>1234</PIN>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>40000</originalAmount>
<originalTxnTime>2016-07-25T15:13:43</originalTxnTime>
<originalSystemTraceId>654321</originalSystemTraceId>
<originalSequenceNumber>456789</originalSequenceNumber>
</giftCardAuthReversal>
</cnpOnlineRequest>

3.3.23.2 Gift Card Auth Reversal Response

A Gift Card Auth Reversal response has the following structure. The response message is identical for
Online and Batch transactions except Online includes the <postDate> element.
<giftCardAuthReversalResponse id="Load Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

277
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<postDate>Date transaction posted</postDate> (Online Only)

<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</giftCardAuthReversalResponse>

Example:
<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<giftCardAuthReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-25T15:13:43</responseTime>
<postDate>2017-03-25</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-25T15:13:38</txnTime>
<refCode>123456</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
</giftCardAuthReversalResponse>
</cnpOnlineResponse>

3.3.24 Gift Card Capture Transactions

The Gift Card Capture transaction allows you to capture (settle) funds previously authorized on a
Closed-loop gift card. Unlike the Capture transaction used for a credit card transaction, a Gift Card
Capture requires you to provide both the capture amount and the original (authorized) amount. If the
transaction is a partial capture, the capture amount will be less than the original amount, with the
remainder available for future capture.

3.3.24.1 Gift Card Capture Request

You must specify the Gift Card Capture request as follows. The structure of the request is identical for
either an Online or a Batch submission.
<giftCardCapture id="Id" reportGroup="iQ Report Group" customerId="Customer Id">
<cnpTxnId>Transaction Id from Auth Response</cnpTxnId>
<captureAmount>Amt of Capture</captureAmount>
<card>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

278
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<originalRefCode>Auth Code from Auth Response</originalRefCode>

<originalAmount>Amount from Auth Request</originalAmount>
<originalTxnTime>txnTime from Auth Response</originalTxnTime>
</giftCardCapture>

Example: Gift Card Capture Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<giftCardCapture id="834262" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>82823534116454002</cnpTxnId>
<captureAmount>40000</captureAmount>
<card>
<type>GC</type>
<number>9000000000000001</number>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>40000</originalAmount>
<originalTxnTime>2016-07-25T15:13:43</originalTxnTime>
</giftCardCapture>
</cnpOnlineRequest>

3.3.24.2 Gift Card Capture Response

A Gift Card Capture response has the following structure. The response message is identical for Online
and Batch transactions except Online includes the <postDate> element.
<giftCardCaptureResponse id="Load Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<accountUpdater>
<fraudResult>
<giftCardResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

279
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</giftCardCaptureResponse>

Example: Gift Card Capture Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<giftCardCaptureResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-25T15:13:43</responseTime>
<postDate>2017-03-25</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-25T15:13:38</txnTime>
<refCode>123456</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
</giftCardCaptureResponse>
</cnpOnlineResponse>

3.3.25 Gift Card Credit Transactions

The Gift Card Credit transaction allows you to refund funds previously captured on a Closed-loop gift
card.

3.3.25.1 Gift Card Credit Request

You must specify the Gift Card Credit request as follows. There are two possible structures for this
transaction type. You use the structure containing the cnpTxnId element, when the Worldpay processed
the capture transaction. You use the structure containing the orderId, when the processor of the
capture transaction was not Worldpay. Typically, this occurs when you first migrate your processing to
Worldpay. The structures of the requests are identical for either an Online or a Batch submission.
<giftCardCredit id="Id" reportGroup="iQ Report Group" customerId="Customer Id">
<cnpTxnId>Transaction Id from Auth Response</cnpTxnId>
<creditAmount>Amt of Credit</captureAmount>
<card>
</giftCardCredit>
or
<giftCardCredit id="Id" reportGroup="iQ Report Group" customerId="Customer Id">
<orderId>Order Id from Capture</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

280
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<creditAmount>Amt of Credit</captureAmount>
<orderSource></orderSource>
<card>
</giftCardCredit>

Example: Online Gift Card Credit Transaction (Worldpay Processed Capture)

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<giftCardCredit id="834262" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>82823534116454002</cnpTxnId>
<creditAmount>40000</creditAmount>
<card>
<type>GC</type>
<number>9000000000000001</number>
</card>
</giftCardCredit>
</cnpOnlineRequest>

Example: Online Gift Card Credit Transaction (Non-Worldpay Processed Capture)

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<giftCardCredit id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>116454002</orderId>
<creditAmount>4000</creditAmount>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
</card>
</giftCardCredit>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

281
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.25.2 Gift Card Credit Response

A Gift Card Credit response has the following structure. The response message is identical for either
request structure, as well as Online and Batch transactions except Online includes the <postDate>
element.
<giftCardCreditResponse id="Load Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<giftCardResponse>
</giftCardCreditResponse>

Example: Gift Card Credit Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<giftCardCreditResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</giftCardCreditResponse>
</cnpOnlineResponse>

3.3.26 Load Transactions

The Load transaction adds funds to an active Gift Card. The load amount cannot exceed the maximum
allowed amount for the Gift Card. If you attempt to load more than the maximum amount, the transaction
will be declined with a response Code of 221 - Over Max Balance.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

282
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.26.1 Load Request

You must specify the Load request as follows. The structure of the request is identical for either an Online
or a Batch submission.
<load id="Load Id" reportGroup="iQ Report Group" customerId="Customer Id">
<orderId>Order Id</orderId>
<amount>Amount to Load</amount>
<orderSource>Order Entry Source</orderSource>
<card>
</load>

Example: Online Load Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<load id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
</load>
</cnpOnlineRequest>

3.3.26.2 Load Response

A Load response has the following structure. The response message is identical for Online and Batch
transactions except Online includes the <postDate> element.
<loadResponse id="Load Id" reportGroup="iQ Report Group"
customerId="Customer Id">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

283
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<giftCardResponse>
</loadResponse>

Example: Load Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<loadResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T15:13:38</txnTime>
<refCode>123456</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>5000</availableBalance>
</giftCardResponse>
</loadResponse>
</cnpOnlineResponse>

3.3.27 Load Reversal Transactions (Online Only)

The Load Reversal transaction reverses the operation of a Load transaction, removing the newly loaded
amount from the Gift Card. The Load Reversal references the associated Load transaction by means of
the cnpTxnId element returned in the Load response. You cannot perform a partial Load Reversal. This
transaction always reverses the full amount of the referenced Load transaction. This transaction type is
available only for Online transactions.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

284
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.27.1 Load Reversal Request

You must structure a Load Reversal request as shown in the following examples.
<loadReversal id="Load Reversal Id" reportGroup="iQ Report Group" customerId="Customer
Id">
<cnpTxnId>Transaction Id from Load Response</cnpTxnId>
<card>
<originalRefCode>Reference Code from Load Response</originalRefCode>
<originalAmount>Amount from Load Transaction</originalAmount>
<originalTxnTime>Transaction Time from Load Response</originalTxnTime>
<originalSystemTraceId>Trace Id from Load Response</originalSystemTraceId>
<originalSequenceNumber>Seq Num from Load Rsp</originalSequenceNumber>
</loadReversal>

Example: Online Load Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<loadReversal id="12345" customerId="Customer Id" reportGroup="Load Reversals">
<cnpTxnId>1234567890123456789</cnpTxnId>
<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</loadReversal>
</cnpOnlineRequest>

3.3.27.2 Load Reversal Response

An Load Reversal response has the following structure.

<loadReversalResponse id="Load Reversal Id" reportGroup="iQ Report Group"

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

285
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</loadReversalResponse>

Example: Online Load Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<loadReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</loadReversalResponse>
</cnpOnlineResponse>

3.3.28 Status Query Transactions (Online Only)

You use a Status Query Transaction to verify the status of an Online transaction submitted within the prior
24 hours. As search criteria, you must submit, at a minimum, the id (the id attribute) and transaction type
(i.e., authorization, deposit, void, etc.) of the original transaction, but to narrow the search, you can also
include the transaction id from the original transaction. This transaction type is available only for Online
transactions.

NOTE: Worldpay must specifically enable you to use this transaction type. Please speak to your
Implementation Consultant or Relationship Manager for additional information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

286
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.28.1 Query Transaction Request

You must structure your Query request as shown below.

<queryTransaction id="GCQueryAuth" reportGroup = "Mer5PM1" customerId="1">
<origId>id Attribute for Original Transaction</origId>
<origActionType>Code for type of Original Transaction</origActionType>
<origCnpTxnId>cnpTxnId from Original Transaction</origcnpTxnId>
<showStatusOnly>Y or N</showStatusOnly>
</queryTransaction>

Example: Query Transaction Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<queryTransaction id="query1" reportGroup="Some RG" customerId="038945">
<origId>834262</origId>
<origActionType>A</origActionType>
<origCnpTxnId>9695061110103040608</origCnpTxnId>
</queryTransaction>
</cnpOnlineRequest>

3.3.28.2 Query Transaction Response

The structure of the Query Transaction response message can vary according to the results of the query.
The results can include a single or multiple transactions that meet the query criteria, no results, if nothing
was found, or a limited response, if a transaction was found, but processing was not complete. The
structure of the response message will be as follows:
<queryTransactionResponse>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<message>Response Message</message>
<location>Processing Platform Location</location>
<matchCount>Number of Matches Found</matchCount>
<results_Max10>
<queryTransactionUnavailableResponse>
or
One or more (10 max) found transaction responses of type specified in the

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

287
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

queryTransaction
</results_Max10>
</queryTransactionResponse>

Example: Query Transaction Response with One Found Transaction

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<queryTransactionResponse id="GCQueryAuth" reportGroup="Mer5PM1" customerId="1">
<response>150</response>
<responseTime>2017-04-06T16:40:24</responseTime>
<message>Original transaction found</message>
<matchCount>1</matchCount>
<results_max10>
<authorizationResponse id="GiftCardAuth" reportGroup="Mer5PM1"
customerId="1">
<cnpTxnId>82827170811986124</cnpTxnId>
<orderId>150330_GCAuth</orderId>
<response>000</response>
<responseTime>2017-04-06T16:40:04</responseTime>
<postDate>2017-04-06</postDate>
<message>Approved</message>
<authCode>111115</authCode>
<fraudResult>
<avsResult>30</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
<giftCardResponse>
<availableBalance>125</availableBalance>
</giftCardResponse>
</authorizationResponse>
</results_max10>
</queryTransactionResponse>
</cnpOnlineResponse>

Example: Query Transaction Response with Multiple Found Transactions

NOTE: This response only occurs if you fail to use unique values for the id attribute, when
submitting transactions.

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"

response="0" message="Valid Format">
<queryTransactionResponse id="GCQueryAuth" reportGroup="Mer5PM1" customerId="1">
<response>150</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

288
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<responseTime>2017-04-06T16:40:24</responseTime>
<message>Original transaction found</message>
<matchCount>2</matchCount>
<results_max10>
<authorizationResponse id="DupeId" reportGroup="Mer5PM1">
<cnpTxnId>82827170811986215</cnpTxnId>
<orderId>150331_DupeAuth2</orderId>
<response>000</response>
<responseTime>2017-04-06T16:40:12</responseTime>
<postDate>2017-04-06</postDate>
<message>Approved</message>
<authCode>055858</authCode>
<fraudResult>
<avsResult>32</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
</authorizationResponse>
<authorizationResponse id="DupeId" reportGroup="Mer5PM1">
<cnpTxnId>82827170811986207</cnpTxnId>
<orderId>150331_DupeAuth1</orderId>
<response>000</response>
<responseTime>2017-04-06T16:40:11</responseTime>
<postDate>2017-04-06</postDate>
<message>Approved</message>
<authCode>111111</authCode>
<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
</authorizationResponse>
</results_max10>
</queryTransactionResponse>
</cnpOnlineResponse>

Example: Query Transaction Response with No Found Transaction

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<queryTransactionResponse id="AuthFromSale" reportGroup="Mer5PM1">
<response>151</response>
<responseTime>2017-04-06T16:40:30</responseTime>
<message>Original transaction not found</message>
<matchCount>0</matchCount>
<results_max10></results_max10>
</queryTransactionResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

289
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</cnpOnlineResponse>

Example: Query Transaction Response with Transaction Found, but not Complete
<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<queryTransactionResponse id="someAuth" reportGroup="Mer5PM1">
<response>152</response>
<responseTime>2016-04-06T16:40:30</responseTime>
<message>Original transaction found but response not yet available</message>
<matchCount>1</matchCount>
<results_max10>
<queryTransactionUnavailableResponse>
<cnpTxnId>82827170811986124</cnpTxnId>
<response>152</response>
<message>Original transaction found but response not yet
available</message>
</queryTransactionUnavailableResponse>
</results_max10>
</queryTransactionResponse>
</cnpOnlineResponse>

3.3.29 Refund Reversal Transactions (Online Only)

The Refund Reversal transaction is a Gift Card only transaction that reverses the operation of a Refund
transaction on the Gift Card. The Refund Reversal references the associated Credit transaction by means
of the cnpTxnId element returned in the Credit response. You cannot perform a partial Refund Reversal.
This transaction always reverses the full amount of the referenced Refund transaction. This transaction
type is available only for Online transactions.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.29.1 Refund Reversal Request

You must structure a Refund Reversal request as shown in the following examples.
<refundReversal id="Refund Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id from CGCredit Response</cnpTxnId>
<card>
<originalRefCode>Reference Code from CGCredit Response</originalRefCode>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

290
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<originalAmount>Amount from CGCredit Transaction</originalAmount>

<originalTxnTime>Transaction Time from CGCredit Response</originalTxnTime>
<originalSystemTraceId>Trace Id from CGCredit Response</originalSystemTraceId>
<originalSequenceNumber>Seq Num from CGCredit Rsp</originalSequenceNumber>
</refundReversal>

Example: Online Refund Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<refundReversal id="12345" customerId="Customer Id" reportGroup="Refund
Reversals">
<cnpTxnId>1234567890123456789</cnpTxnId>
<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</refundReversal>
</cnpOnlineRequest>

3.3.29.2 Refund Reversal Response

An Refund Reversal response has the following structure.

<refundReversalResponse id="Refund Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

291
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</refundReversalResponse>

Example: Online Refund Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<refundReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</cnpOnlineResponse>

3.3.30 Register Token Transactions

The Register Token transaction enables you to submit a credit card number, Direct Debit account
number, or Registration Id to us and receive a token in return. While you can submit Register Token
transactions at any time, typically, you would make use of this transactions when initially converting to the
use of tokens. In this case you would submit large quantities of credit cards/Direct Debit account numbers
in Batches and replace them in your database with the tokens returned.

NOTE: When initially tokenizing your customer database, Worldpay recommends that you collect all
distinct credit card numbers and submit the information in one or more large Session files. When
you receive the response file, parse the returned token information to your database, replacing the
card numbers.

3.3.30.1 Register Token Request

You must specify the Register Token request as follows. The structure of the request is identical for either
an Online or a Batch submission. The child elements used differ depending upon whether you are
registering a credit card account, an Direct Debit account, or submitting a Registration Id.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

292
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts and stores
the value on a temporary basis for later use in a tokenized Auth/Sale transaction submitted without the
value. This is done to accommodate merchant systems/workflows where the security code is available at
the time of token registration, but not at the time of the Auth/Sale. If for some reason you need to change
the value of the security code supplied at the time of the token registration, use an
updateCardValidationNumOnToken transaction. To use the store value when submitting an
Auth/Sale transaction, set the cardValidationNum value to 000.

NOTE: The use of the cardValidationNum element in the registertokenRequest only

applies when you submit an accountNumber element.

For credit cards:

<registerTokenRequest id="Id" reportGroup="iQ Report Group">
<orderId>Order Id</orderId>
<accountNumber>Card Account Number</accountNumber>
<cardValidationNum>CVV2/CVC2/CID</cardValidationNum>
</registerTokenRequest>
For credit cards with encrypted account info:
<registerTokenRequest id="Id" reportGroup="iQ Report Group">
<encryptionKeyId>1234567890</encryptionKeyId>
<orderId>Order Id</orderId>
<encryptedAccountNumber>Encrypted Account Number</encryptedAccountNumber>
<encryptedCardValidationNum>Encrypted CVV2/CVC2/CID</encryptedCardValidationNum>
</registerTokenRequest>
For Direct Debit accounts:
<registerTokenRequest id="Id" reportGroup="iQ Report Group">
<orderId>Order Id</orderId>
<echeckForToken>
<accNum>Account Number</accNum>
<routingNum>Routing Number</routingNum>
</echeckForToken>
</registerTokenRequest>
For Registration Ids:
<registerTokenRequest id="Id" reportGroup="iQ Report Group">
<orderId>Order Id</orderId>
<paypageRegistrationId>
</registerTokenRequest>
For Mobile POS transactions:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

293
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<registerTokenRequest id="Id" reportGroup="iQ Report Group">

<orderId>Order Id</orderId>
<mpos>
<ksn>Key Serial Number</ksn>
<formatId>Format of Encrypted Track</formatId>
<encryptedTrack>Encrypted Track Data</encrytpedTrack>
<track1Status>Track Read Status - 0 or 1</track1Status>
<track2Status>Track Read Status - 0 or 1</track2Status>
</mpos>
</registerTokenRequest>
For Apple Pay transactions:
<registerTokenRequest id="Id" reportGroup="iQ Report Group">
<orderId>Order Id</orderId>
<applepay>
<data>Encrypted Payment Data</data>
<header>
<applicationData>Hash of Application Data Property</applicationData>
<ephemeralPublicKey>Ephemeral Public Key</ephemeralPublicKey>
<publicKeyHash>Merchant Cert Encoded Public Key</publicKeyHash>
<transactionId>Transaction Id from Device</transactionId>
</header>
<signature>Signature of Payment and Header Data</signature>
<version>Payment Token Version</version>
</applepay>
</registerTokenRequest>

Example: Batch Register Token Request - Credit Card

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numTokenRegistrations="1" merchantId="000902">
<registerTokenRequest id="99999" reportGroup="RG1">
<orderId>F12345</orderId>
<accountNumber>4005101001000002</accountNumber>
<cardValidationNum>999</cardValidationNum>
</registerTokenRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

294
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</batchRequest>
</cnpRequest>

Example: Batch Register Token Request - Direct Debit

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numTokenRegistrations="1" merchantId="000902">
<registerTokenRequest id="99999" reportGroup="RG1">
<orderId>F12345</orderId>
<echeckForToken>
<accNum>12345678901234567</accNum>
<routingNum>000010101</routingNum>
</echeckForToken>
</registerTokenRequest>
</batchRequest>
</cnpRequest>

Example: Batch Register Token Request - paypageRegistationId

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<batchRequest id="01234567" numTokenRegistrations="1" merchantId="000902">
<registerTokenRequest id="99999" reportGroup="RG1">
<orderId>F12345</orderId>
<paypageRegistrationId>12345678901234567</paypageRegistrationId>
</registerTokenRequest>
</batchRequest>
</cnpRequest>

Example: Online Register Token Request - Encrypted Account Number and CVV
<cnpOnlineRequest version="12.5" xmlns="http://www.vantivcnp.com/schema"
merchantId="yourMerchantIdentString">
<authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

295
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<user>yourUsername</user>
<password>yourPassword</password>
</authentication>
<registerTokenRequest id="002" reportGroup="encrypt">
<encryptionKeyId>1</encryptionKeyId>
<encryptedAccountNumber>l2PRNMUV5l9Hq7h6l/Ae8gDaiatUUfJ7DLim3+l7zfq54njT
gQJ0V2ExXnIpQuTGtNlKhesg+cXz8Igx/4kJQTGss2MeCI7vwHAC19/32+p1iW2LaTLzmMj+T3jH72IE
EwcWyT2UhxJts6LcXOZn1+qi1thOENIXALBcB5OUjQWJIYy0aciZu/UsX0N8YXmbJ18dZJDuyo5bkhsg
zKlM5pfYvUoR0ReC39KtNWW95XR0/6w7v9I1ncREmyZQ9vr0+C8yz6O9w+1TW0xqafSWoZW02NBxmpcZ
6Rnt8xJwnxLmsgNn8J0kR9Yq2XiBmAPWXmR7pi2FYkmNOsEHbWHNCw==</encryptedAccountNumber
>
<encryptedCardValidationNum>H3OM9kbPWks0OlE+rlqy5zdOllnp+Zs/2WwfXxtEvVbt
lc1slWb/wiAWOaNqrNBl2BPEOfaftOHFHNH6mqNVN3kElW8u8AOstQpeA4Qf5a6j1UaaC9a/VNgFz6ln
7BHn0N1VWxIh5lt1JJ31w1dHQzdpapHitqjEyUXdgir5UQJ+3QJ/+Gjf8Ucv/9b9+sPxpwJAdCMbvc1y
fvxFcXWq0zX+j/RJwwMglKcFndO+o4sil1+HkZW4CKVADn54c31PA0cjQR+dV19DYkrV1WQmFYH45CDm
07OkGb2D1YFVEQN/b+UeVCuqDIoUbEBS9FaeM5qT6Va4WmP29rLRNruGgA==</encryptedCardValid
ationNum>
</registerTokenRequest>
</cnpOnlineRequest>alidationNum>

3.3.30.2 Register Token Response

There is no structural difference an Online and Batch response; however, some child elements change
depending upon whether the token is for a credit card account or an Direct Debit account. The response
will have one of the following structures.
Register Token response for Credit Cards:
<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>Transaction Id</cnpTxnId>
<cnpToken>Token</cnpToken>
<bin>BIN</bin>
<type>Method of Payment</type>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Response Time</responseTime>
<accountRangeId>ID of Account Range</accountRangeId>
</registerTokenResponse>
Register Token response for eChecks:
<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>Transaction Id</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

296
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpToken>Token</cnpToken>
<type>Method of Payment</type>
<eCheckAccountSuffix>Last 3 of Acct Number</eCheckAccountSuffix>
<response>Response Code</response>
<responseTime>Response Time</responseTime>
<message>Response Message</message>

</registerTokenResponse>

Register Token response for ApplePay:

<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>Transaction Id</cnpTxnId>
<cnpToken>Token</cnpToken>
<type>Method of Payment</type>
<response>Response Code</response>
<responseTime>Response Time</responseTime>
<message>Response Message</message>
<applepayResponse>
<applicationExpirationDate>App PAN Exp Date</applicationExpirationDate>
<currencyCode>Currency Code</currencyCode>
<transactionAmount>Amount of Transaction</transactionAmount>
<cardholderName>Name of cardholder</cardholderName>
<deviceManufacturerIdentifier>Device Mfr Id</deviceManufacturerIdentifier>
<paymentDataType>Type of Payment Data</paymentDataType>
<onlinePaymentCryptogram>Payment Cryptogram</onlinePaymentCryptogram>
<eciIndicator>eCommerece Indicator</eciIndicator>
</applepayResponse>

</registerTokenResponse>

Register Token for Android Pay:

<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>Transaction Id</cnpTxnId>
<cnpToken>Token</cnpToken>
<type>Method of Payment</type>
<response>Response Code</response>
<responseTime>Response Time</responseTime>
<message>Response Message</message>
<androidpayResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

297
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cryptogram>Payment Cryptogram</cryptogram>
<expMonth>Expiration Month</expMonth>
<expYear>Expiration Year</expYear>
<eciIndicator>eCommerece Indicator</eciIndicator>
</androidpayResponse>
</registerTokenResponse>

Example: Batch Register Token Response - Credit Card

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>21122700</cnpTxnId>
<cnpToken>1111000100360002</cnpToken>
<bin>400510</bin>
<type>VI</type>
<response>801</response>
<responseTime>2016-10-26T17:21:51</responseTime>
<message>Account number was successfully registered</message>
</registerTokenResponse>
</batchResponse>
</cnpResponse>

Example: Batch Register Token Request - Direct Debit

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<registerTokenResponse id="99999" reportGroup="RG1">
<cnpTxnId>21122700</cnpTxnId>
<cnpToken>1111000100360002</cnpToken>
<type>VI</type>
<eCheckAccountSuffix>511</eCheckAccountSuffix>
<response>801</response>
<responseTime>2016-10-26T17:21:51</responseTime>
<message>Account number was successfully registered</message>
</registerTokenResponse>
</batchResponse>
</cnpResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

298
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.31 RFR Transactions (Batch Only)

An RFR (Request For Response) transaction enables you to request a response file for a previously
submitted Batch. You make the request by submitting either the cnpSessionId of the Batch, or in the
case of a request for an Account Updater file, the accountUpdateFileRequestData element.

NOTE: The use of RFR transactions for Account Updater files apply only to the legacy Account
Updater solution.

3.3.31.1 RFR Request

You must specify the RFR request as follows.

<RFRRequest>
<cnpSessionId | accountUpdateFileRequestData>
</RFRRequest>

Example: RFR Request for Payment Transaction Batch

The following example shows an RFR request for the response, with 7766554321 as the value of the
<cnpSessionId> element.
<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="0">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<RFRRequest>
<cnpSessionId>7766554321</cnpSessionId>
</RFRRequest>
</cnpRequest>

Example: RFR Request for an Account Updater File

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="0">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>
<RFRRequest>
<merchantId>100</merchantId>
<postDate>2017-01-15</postDate>
</RFRRequest>
</cnpRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

299
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.31.2 RFR Response

When using an RFR request to obtain the response file for a payment transaction Batch, the RFR
response is exactly the same as the original session response associated with the <cnpSessionId> you
submitted in the RFR request. The session ID returned in the response will be the session ID of the
original session.
When using an RFR request in an Account Updater scenario, you will receive either an Account Updater
Completion response, if the file is ready, or an Account Updater RFR “not ready” response, as shown in
the example below.

Example: Account Updater RFR “not ready” Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema">
<RFRResponse response="1" message="The account update file is not ready yet.
Please try again later.">
</RFRResponse>
</cnpResponse>

3.3.32 Sale Transactions

The Sale transaction enables you to both authorize fund availability and deposit those funds by means of
a single transaction. The Sale transaction is also known as a conditional deposit, because the deposit
takes place only if the authorization succeeds. If the authorization is declined, the deposit will not be
processed.

NOTE: If the authorization succeeds, the deposit is processed automatically, regardless of the AVS,
CVV2, CVC2, or CID response, except for American Express transactions. For American Express, a
failure to match the security code (CID) results in a declined transaction with the Response Reason
Code of 352 - Decline CVV2/CID Fail.

3.3.32.1 Sale Request

You must specify the Sale request as follows. The structure of the request is identical for either an Online
or a Batch submission.

NOTE: When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts
and stores the value on a temporary basis for later use in a tokenized Auth/Sale transaction
submitted without the value. To use the stored value when submitting an Auth/Sale transaction, set
the cardValidationNum value to 000.

<sale id="Sale Id" reportGroup="iQ Report Group" customerId="Customer Id">

<orderId>Order Id</orderId>
<amount>Authorization Amount</amount>
<secondaryAmount>Secondary Amount</secondaryAmount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

300
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderSource>Order Entry Source</orderSource>

<customerInfo>
<billToAddress>
<shipToAddress>
[<card>|<paypage>|<token>|<paypal>|<mpos>|<applepay>] (Choice)
<cardholderAuthentication>
<customBilling>
<taxType>payment or fee</taxType>
<enhancedData>
<processingInstructions>
<pos>
<payPalOrderComplete>Send true in the final Sale</payPalOrderComplete>
<allowPartialAuth>
<healthcareIIAS>
<lodgingInfo>
<filtering>
<merchantData>
<recyclingRequest> (for Recycling Engine merchants)
<fraudFilterOverride>
<recurringRequest> (for Recurring Engine merchants)
<debtRepayment>true or false</debtRepayment>
<advancedFraudChecks>
<wallet>
<processingType>processingType Enum</processingType>
<originalNetworkTransactionId>Network Txn Value</originalNetworkTransactionId>
<originalTransactionAmount>Amount from Orig Txn</originalTransactionAmount>
<pinlessDebitRequest>
<skipRealtimeAU>True or Flase</skipRealtimeAU>
<merchantCategoryCode>MCC Value</merchantCategoryCode>
</sale>

Example: Batch Sale Request

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
numBatchRequests="1">
<authentication>
<user>userName</user>
<password>password</password>
</authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

301
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<batchRequest id="01234567" numSales="1" saleAmount="12522" merchantId="100">

<sale id="AX54321678" reportGroup="RG27">
<orderId>12z58743y1</orderId>
<amount>12522</amount>
<orderSource>ecommerce</orderSource>
<billToAddress>
<name>John Doe</name>
<addressLine1>123 4th street</addressLine1>
<addressLine2>Apt. 20</addressLine2>
<addressLine3>second floor</addressLine3>
<city>San Jose</city>
<state>CA</state>
<zip>95032</zip>
<country>USA</country>
<email>[email protected]</email>
<phone>408-555-1212</phone>
</billToAddress>
<card>
<type>MC</type>
<number>5186005800001012</number>
<expDate>1110</expDate>
</card>
</sale>
</batchRequest>
</cnpRequest>

Example: Online Sale Request

NOTE: The example below includes an <orderSource> value of 3dsAuthenticated and includes
the <cardholderAuthentication> information. Use this <orderSource> value only if you are
a 3DS merchant and authenticated the cardholder.
Also, the values for the <authenticationValue> and <authenticationTransactionId>
elements in the example below have been truncated.

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"

merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<sale id="1" reportGroup="ABC Division" customerId="038945">
<orderId>5234234</orderId>
<amount>40000</amount>
<orderSource>3dsAuthenticated</orderSource>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

302
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<billToAddress>
<name>John Smith</name>
<addressLine1>100 Main St</addressLine1>
<addressLine2>100 Main St</addressLine2>
<addressLine3>100 Main St</addressLine3>
<city>Boston</city>
<state>MA</state>
<zip>12345</zip>
<country>US</country>
<email>[email protected]</email>
<phone>555-123-4567</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>1210</expDate>
<cardValidationNum>555</cardValidationNum>
</card>
<cardholderAuthentication>
<authenticationValue>BwABBJQ1AgJDUCAAAAAAA=</authenticationValue>
<authenticationTransactionId>gMV75TAgk=</authenticationTransactionId>
</cardholderAuthentication>
<customBilling>
<phone>8888888888</phone>
<descriptor>bdi*Vantiv Test</descriptor>
</customBilling>
<enhancedData>
<customerReference>PO12345</customerReference>
<salesTax>125</salesTax>
<taxExempt>false</taxExempt>
<discountAmount>0</discountAmount>
<shippingAmount>495</shippingAmount>
<dutyAmount>0</dutyAmount>
<shipFromPostalCode>01851</shipFromPostalCode>
<destinationPostalCode>01851</destinationPostalCode>
<destinationCountryCode>USA</destinationCountryCode>
<invoiceReferenceNumber>123456</invoiceReferenceNumber>
<orderDate>2016-08-14</orderDate>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>00</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

303
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

</detailTax>
<lineItemData>
<itemSequenceNumber>1</itemSequenceNumber>
<itemDescription>chair</itemDescription>
<productCode>CH123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<taxAmount>125</taxAmount>
<lineItemTotal>9380</lineItemTotal>
<lineItemTotalWithTax>9505</lineItemTotalWithTax>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>93.80</unitCost>
<detailTax>
<taxIncludedInTotal>true</taxIncludedInTotal>
<taxAmount>55</taxAmount>
<taxRate>0.0059</taxRate>
<taxTypeIdentifier>03</taxTypeIdentifier>
<cardAcceptorTaxId>011234567</cardAcceptorTaxId>
</detailTax>
</lineItemData>
<lineItemData>
<itemSequenceNumber>2</itemSequenceNumber>
<itemDescription>table</itemDescription>
<productCode>TB123</productCode>
<quantity>1</quantity>
<unitOfMeasure>EACH</unitOfMeasure>
<lineItemTotal>30000</lineItemTotal>
<itemDiscountAmount>0</itemDiscountAmount>
<commodityCode>300</commodityCode>
<unitCost>300.00</unitCost>
</lineItemData>
</enhancedData>
</sale>
</cnpOnlineRequest>

3.3.32.2 Sale Response

The Sale response message is identical for Online and Batch transactions except Online includes the
postDate element. The Sale response has the following structure:
<saleResponse id="Sale Id" reportGroup="iQ Report Group" customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

304
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<orderId>Order Id</orderId>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date of Posting</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<authCode>Approval Code</authCode>
<approvedAmount>Approved amount for partial Auth</approvedAmount>
<accountInformation>
<fraudResult>
<tokenResponse> (for Tokenized merchants submitting card data)
<enhancedAuthResponse>
<accountUpdater>
<recyclingResponse> (included for declined Auths if featrure is enabled)
<recurringResponse> (for Recurring Engine merchants)
<giftCardResponse> (included if Gift Card is Method of Payment)
<applepayResponse> (included if an ApplePay transaction)
<cardSuffix>Card Last 4</cardSuffix> (included for ApplePay using VI or MC)
<androidpayResponse>
<networkTransactionId>Txn ID returned from network</networkTransactionId>
<pinlessDebitResponse> (included if approved by Debit Network via Prime PINless Debit
service)
</saleResponse>

Example: Batch Sale Response

<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" id="123"
response="0" message="Valid Format" cnpSessionId="987654321">
<batchResponse id="01234567" cnpBatchId="4455667788" merchantId="100">
<saleResponse id="AX54321678" reportGroup="RG27">
<cnpTxnId>84568456</cnpTxnId>
<response>000</response>
<orderId>12z58743y1</orderId>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
<authCode>123456</authCode>
<fraudResult>
<avsResult>00</avsResult>
</fraudResult>
</saleResponse>
<saleResponse id="AX54325432" reportGroup="RG12">
<cnpTxnId>84568457</cnpTxnId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

305
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<response>000</response>
<orderId>12z58743y7</orderId>
<responseTime>2016-09-01T10:24:31</responseTime>
<message>Approved</message>
<authCode>123456</authCode>
<fraudResult>
<avsResult>00</avsResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
</saleResponse>
</batchResponse>
</cnpResponse>

Example: Online Sale Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<saleResponse id="1" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>
<orderId>23423434</orderId>
<responseTime>2016-07-11T14:48:46</responseTime>
<postDate>2011-07-11</postDate>
<message>Approved</message>
<authCode>123457</authCode>
<fraudResult>
<avsResult>01</avsResult>
<cardValidationResult>U</cardValidationResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
</saleResponse>
</cnpOnlineResponse>

Example: Online Sale Response for Tokenized Merchant Sending Card Data
A tokenized merchant that includes card information in the request receives a response message that
includes the token element. The example below is an Online response.
<saleResponse id="99999" reportGroup="RG1" customerId="444">
<cnpTxnId>21200000028606</cnpTxnId>
<response>000</response>
<orderId>F12345</orderId>
<responseTime>2016-10-26T17:30:00</responseTime>
<postDate>2011-10-26</postDate>
<message>Approved</message>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

306
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<authCode>089510</authCode>
<fraudResult>
<avsResult>11</avsResult>
<cardValidationResult>P</cardValidationResult>
</fraudResult>
<tokenResponse>
<cnpToken>1111000100329510</cnpToken>
<tokenResponseCode>801</tokenResponseCode>
<tokenMessage>Account number was successfully registered</tokenMessage>
<type>VI</type>
<bin>432610</bin>
</tokenResponse>
</saleResponse>

Example: Online Sale Response with Account Updater Info

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<saleResponse id="1" reportGroup="ABC Division" customerId="038945">
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>
<orderId>23423434</orderId>
<responseTime>2017-07-11T14:48:46</responseTime>
<postDate>2011-07-11</postDate>
<message>Approved</message>
<authCode>123457</authCode>
<accountUpdater>
<originalCardInfo>
<type>VI</type>
<number>4234823492346234</number>
<expDate>1112</expDate>
</originalCardInfo>
<newCardInfo>
<type>VI</type>
<number>4234823490005777</number>
<expDate>1114</expDate>
</newCardInfo>
</accountUpdater>
<fraudResult>
<avsResult>01</avsResult>
<cardValidationResult>U</cardValidationResult>
<authenticationResult>2</authenticationResult>
</fraudResult>
</saleResponse>
</cnpOnlineResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

307
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

Example: Batch Sales Response with Recurring Info

The following is an example of the Recurring Response file produced daily to provide information about
the transactions submitted by the Recurring Engine. This file is delivered via sFTP.
<cnpResponse version="12.0" xmlns="http://www.vantivcnp.com/schema" response="0"
message="Valid Format" cnpSessionId="82912082263408653">
<batchResponse cnpBatchId="82912082263408661" merchantId="101">
<saleResponse reportGroup="Default Report Group">
<cnpTxnId>82912082263409610</cnpTxnId>
<response>000</response>
<orderId>recurring_appr1</orderId>
<responseTime>2017-01-30T20:15:51</responseTime>
<message>Approved</message>
<authCode>11111</authCode>
<fraudResult>
<avsResult>01</avsResult>
</fraudResult>
<recurringResponse>
<subscriptionId>82912081866997773</subscriptionId>
<responseCode>473</responseCode>
<responseMessage>Scheduled recurring payment processed</responseMessage>
<recurringTxnId>211014241510</recurringTxnId>
</recurringResponse>
</saleResponse>
<saleResponse reportGroup="Default Report Group">
<cnpTxnId>82912082263410311</cnpTxnId>
<response>000</response>
<orderId>recurring_appr2</orderId>
<responseTime>2017-01-30T20:15:55</responseTime>
<message>Approved</message>
<authCode>123457</authCode>
<fraudResult>
<avsResult>00</avsResult>
</fraudResult>
<recurringResponse>
<subscriptionId>82912081866997799</subscriptionId>
<responseCode>473</responseCode>
<responseMessage>Scheduled recurring payment processed</responseMessage>
<recurringTxnId>211014245016</recurringTxnId>
</recurringResponse>
</saleResponse>
<saleResponse reportGroup="Default Report Group">

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

308
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<cnpTxnId>82912082263410337</cnpTxnId>
<response>110</response>
<orderId>recurring_decline1</orderId>
<responseTime>2017-01-30T20:15:56</responseTime>
<message>Insufficient Funds</message>
<fraudResult>
<avsResult>34</avsResult>
</fraudResult>
<recyclingResponse>
<recycleEngineActive>true</recycleEngineActive>
</recyclingResponse>
<recurringResponse>
<subscriptionId>82912081866997807</subscriptionId>
<responseCode>473</responseCode>
<responseMessage>Scheduled recurring payment processed</responseMessage>
<recurringTxnId>211014245115</recurringTxnId>
</recurringResponse>
</saleResponse>
<saleResponse reportGroup="Default Report Group">
<cnpTxnId>82912082263410378</cnpTxnId>
<response>110</response>
<orderId>recurring_decline3</orderId>
<responseTime>2017-01-30T20:15:56</responseTime>
<message>Insufficient Funds</message>
<fraudResult>
<avsResult>34</avsResult>
</fraudResult>
<recyclingResponse>
<recycleEngineActive>true</recycleEngineActive>
</recyclingResponse>
<recurringResponse>
<subscriptionId>82912081866997807</subscriptionId>
<responseCode>473</responseCode>
<responseMessage>Scheduled recurring payment processed</responseMessage>
<recurringTxnId>211014245313</recurringTxnId>
</recurringResponse>
</saleResponse>
</batchResponse>
</cnpResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

309
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.33 Translate to Low Value Token Transaction

You use this transaction type to create a low value token for a submitted high value token. You can then
provide the low value token to a third party service provider, who requires access to the PAN information.
The third party can redeem the LVT for the PAN information via an
onlineAccountNumberAccessRequest transaction.

NOTE: Please refer to the OmniToken Translator Transaction Info document for additional
information about this transaction type.

3.3.33.1 Translate to Low Value Token Request

You must specify the Translate to Low Value Token request as follows. The structure of the request is
identical for either an Online or a Batch submission.
<translateToLowValueTokenRequest id="Xlate1" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<token>Token Value</token>
</translateToLowValueTokenRequest>

Example: Translate to Low Value Token Request

3.3.33.2 Translate to Low Value Token Response

The Translate to Low Value Token response message is identical for Online and Batch transactions. The
Sale response has the following structure:
<translateToLowValueTokenResponse id="Xlate1" reportGroup="iQ Report Group"
customerId="Customer Id">
<orderId>Order Id</orderId>
<paypageRegistrationId>Low Value Token</paypageRegistrationId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Date and Time in GMT</responseTime>
</translateToLowValueTokenResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

310
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.34 Unload Transactions

The Unload transaction removes funds from an active Gift Card. The unload amount cannot exceed the
available balance on the Gift Card. If you attempt to unload more than the available balance, the
transaction will be declined with a response Code of 209 - Invalid Amount.

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.34.1 Unload Request

You must specify the Unload request as follows. The structure of the request is identical for either an
Online or a Batch submission.
<unload id="Unload Id" reportGroup="iQ Report Group" customerId="Customer Id">
<orderId>Order Id</orderId>
<amount>Amount to Load</amount>
<orderSource>Order Entry Source</orderSource>
<card>
</unload>

Example: Online Unload Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<unload id="834262" reportGroup="ABC Division" customerId="038945">
<orderId>65347567</orderId>
<amount>40000</amount>
<orderSource>ecommerce</orderSource>
<card>
<type>GC</type>
<number>9000000000000001</number>
<pin>1234</number>
</card>
</onload>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

311
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.34.2 Unload Response

An Unload response has the following structure. The response message is identical for Online and Batch
transactions except Online includes the <postDate> element.
<unloadResponse id="Unload Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate> (Online Only)
<message>Response Message</message>
<location>Processing Platform Location</location>
<fraudResult>
<giftCardResponse>
</unloadResponse>

Example: Unload Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<unloadResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</unloadResponse>
</cnpOnlineResponse>

3.3.35 Unload Reversal Transactions (Online Only)

The Unload Reversal transaction reverses the operation of a Unload transaction, returning the value
removed from the Gift Card by the Unload transaction. The Unload Reversal references the associated
Unload transaction by means of the cnpTxnId element returned in the Unload response. You cannot
perform a partial Unload Reversal. This transaction always reverses the full amount of the referenced
Unload transaction. This transaction type is available only for Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

312
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: You must be enabled for (Closed Loop) Gift Card transactions to use this transaction type.
Please consult your Relationship Manager for additional information about Gift Card transactions.

3.3.35.1 Unload Reversal Request

You must structure a Unload Reversal request as shown in the following examples.
<unloadReversal id="Unload Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id from CGCredit Response</cnpTxnId>
<card>
<originalRefCode>Reference Code from Unload Response</originalRefCode>
<originalAmount>Amount from Unload Transaction</originalAmount>
<originalTxnTime>Transaction Time from Unload Response</originalTxnTime>
<originalSystemTraceId>Trace Id from Unload Response</originalSystemTraceId>
<originalSequenceNumber>Seq Num from Unload Rsp</originalSequenceNumber>
</unloadReversal>

Example: Online Unload Reversal Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<unloadReversal id="12345" customerId="Customer Id" reportGroup="Unload
Reversals">
<cnpTxnId>1234567890123456789</cnpTxnId>
<card>
<type>GC</type>
<number>1234102000003558</number>
<cardValidationNum>888</cardValidationNum>
<pin>1234</pin>
</card>
<originalRefCode>123456</originalRefCode>
<originalAmount>1900</originalAmount>
<originalTxnTime>2017-03-21T10:02:46</originalTxnTime>
<originalSystemTraceId>678901</originalSystemTraceId>
<originalSequenceNumber>123456</originalSequenceNumber>
</unloadReversal>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

313
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.35.2 Unload Reversal Response

An Unload Reversal response has the following structure.

<unloadReversalResponse id="Unload Reversal Id" reportGroup="iQ Report Group"
customerId="Customer Id">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date transaction posted</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
<giftCardResponse>
</unloadReversalResponse>

Example: Online Unload Reversal Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<unloadReversalResponse id="834262" reportGroup="ABC Division">
<cnpTxnId>9695064321</cnpTxnId>
<response>000</response>
<responseTime>2017-03-22T15:13:43</responseTime>
<postDate>2017-03-22</postDate>
<message>Approved</message>
<giftCardResponse>
<txnTime>2017-03-22T12:00:00</txnTime>
<refCode>003558</refCode>
<systemTraceId>834528</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>0</availableBalance>
</giftCardResponse>
</unloadReversalResponse>
</cnpOnlineResponse>

3.3.36 Update Plan Transactions

You use the Update Plan transaction to activate/deactivate Plans associated with recurring payments.
When you deactivate a Plan, by setting the active flag to false, you can no longer reference that Plan
for use with subscriptions. Existing subscriptions already using the deactivated Plan will continue to use
the Plan until the subscription is either modified or completed. You can also reactivate a deactivated Plan
by updating the Plan and setting the active flag to true.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

314
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.36.1 Update Plan Request

You must structure an Update Plan request as shown in the following examples. The structure of the
request is identical for either an Online or a Batch submission.
<updatePlan>
<planCode>Plan Reference Code</planCode>
<active>true or false</active>
</updatePlan>

Example: Online Update Plan Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>
<updatePlan>
<planCode>Reference_Code</planCode>
<active>false</active>
</updatePlan>
</cnpOnlineRequest>

3.3.36.2 Update Plan Response

An Update Plan response has the following structure. The response message is identical for Online and
Batch transactions.
<updatePlanResponse>
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Date and Time in GMT</responseTime>
<planCode>Plan Reference Code</subscriptionId>
</updatePlanResponse>

Example: Online Update Plan Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<updatePlanResponse>
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

315
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<message>Approved</message>
<responseTime>2017-07-11T14:48:46</responseTime>
<planCode>Reference_Code</planCode>
</updatePlanResponse>
</cnpOnlineResponse>

3.3.37 Update Subscription Transactions

The Update Subscription transaction allows you to change certain subscription information associated
with a recurring payment. Using this transaction type you can change the plan, card, billing information,
and/or billing date. You can also create, update, or delete a Discount and/or an Add On.

NOTE: You can include multiple create, update, and delete Discounts and Add On operations in a
single updateSubscription transaction.

3.3.37.1 Update Subscription Request

You must structure an Update Subscription request as shown in the following examples. The structure of
the request is identical for either an Online or a Batch submission.
<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<planCode>Plan Reference Code</subscriptionId>
<billToAddress>
[ <card> | <paypage> | <token>]
<billingDate>New Billing Date</billingDate>
<createDiscount>
<updateDiscount>
<deleteDiscount>
<createAddOn>
<updateAddOn>
<deleteAddOn>
</updateSubscription

Example: Online Update Subscription Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>password</password>
</authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

316
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<updateSubscription>
<subscriptionId>1234</subscriptionId>
<planCode>Gold_Monthly</planCode>
<billToAddress>
<name>John Smith</name>
<addressLine1>100 Main St</addressLine1>
<city>Boston</city>
<state>MA</state>
<zip>12345</zip>
<country>US</country>
<email>[email protected]</email>
<phone>555-123-4567</phone>
</billToAddress>
<card>
<type>VI</type>
<number>4005550000081019</number>
<expDate>1210</expDate>
<cardValidationNum>555</cardValidationNum>
</card>
<deleteDiscount>
<discountCode>1GBExtra</discountCode>
</deleteDiscount>
<createAddOn>
<addOnCode>1WF</addOnCode>
<name>One_GB_Extra</name>
<amount>500<amount>
<startDate>2017-07-15</startDate>
<endDate>2017-07-22</endDate>
</createAddOn>
</updateSubscription>
</cnpOnlineRequest>

3.3.37.2 Update Subscription Response

An Update Subscription response has the following structure. The response message is identical for
Online and Batch transactions.
<updateSubscriptionResponse>
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

317
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

<responseTime>Date and Time in GMT</responseTime>

<subscriptionId>ID of Subscription Canceled</subscriptionId>
<tokenResponse> (For Tokenized Merchants submitting Card/Paypage)
</cancelSubscriptionResponse>

Example: Online Update Subscription Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<updateSubscriptionResponse>
<cnpTxnId>1100030055</cnpTxnId>
<response>000</response>
<message>Approved</message>
<responseTime>2017-06-11T14:48:46</responseTime>
<subscriptionId>123457</subscriptionId>
</updateSubscriptionResponse>
</cnpOnlineResponse>

3.3.38 Update Card Validation Number Transactions

When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts and stores
the value on a temporary basis for later use in a tokenized Auth/Sale transaction submitted without the
value. This is done to accommodate merchant systems/workflows where the security code is available at
the time of token registration, but not at the time of the Auth/Sale. If for some reason you need to change
the value of the security code supplied at the time of the token registration, use an
updateCardValidationNumOntoken transaction.

NOTE: You should only use this transaction type if you had previously submitted the account
number and security code in a registerTokenRequest transaction and now need to change the
CVV2/CVC2/CID value.

3.3.38.1 Update Card Validation Number Request

The updateCardValidationNumOnToken transaction has the following structure:

<updateCardValidationNumOnToken id = "Update Id" customerId="Customer Id"
reportGroup="iQ Report Group">
<orderId>Order Id</orderId>
<cnpToken>Token</cnpToken>
<cardValidationNum>CVV2/CVC2/CID Value</cardValidationNum>
</updateCardValidationNumOnToken>

Example: Online Update Card Validation Number Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

318
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

merchantId="100">
<updateCardValidationNumOnToken id="99999" customerId="444" reportGroup="RG1">
<orderId>F12345</orderId>
<cnpToken>1111000101039449</cnpToken>
<cardValidationNum>987</cardValidationNum>
</updateCardValidationNumOnToken>
</cnpOnlineRequest>

3.3.38.2 Update Card Validation Number Response

The updateCardValidationNumOnTokenResponse transaction has the following structure:

<updateCardValidationNumOnTokenResponse id="Update Id" reportGroup="iQ Report Group">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<message>Response Message</message>
<location>Processing Platform Location</location>
<responseTime>Date and Time in GMT</responseTime>
</updateCardValidationNumOnTokenResponse>

Example: Online Update Card Validation Number Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<updateCardValidationNumOnTokenResponse id="99999" customerId="444"
reportGroup="RG1">
<cnpTxnId>21122700</cnpTxnId>
<response>803</response>
<message>Card Validation Number Updated</message>
<responseTime>2017-06-09T17:21:51</responseTime>
</updateCardValidationNumOnTokenResponse>
</cnpOnlineResponse>

3.3.39 Void Transactions (Online Only)

You use a Void transaction to cancel a settlement transaction prior to us delivering the transaction to the
card brands (see Multiple Daily Delivery on page 5). You can void Capture, Credit, and Sale transactions.
Also, if you use Recycling Engine, you can use the void transaction to halt the recycling of a sale
transaction. In this case the response may include the recycling element. (see Using Void to Halt
Recycling Engine on page 78).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

319
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

NOTE: Before submitting a Void, please allow a minimum of 60 seconds to elapse after submitting
the transaction you wish to void. This timing ensures our system fully records the first (to be voided)
transaction in our database.
Do not use Void transactions to void an Authorization. To remove an Authorization use an
Authorization Reversal transaction (see Authorization Reversal Transactions on page 210.)

If you attempt to void a transaction after the cutoff time, the system returns a response code of 362 and
the message, Transaction Not Voided - Already Settled. In this situation, you can cancel the original
transaction by using its reverse transaction, as shown in Table 3-2.

TABLE 3-2 Cancelling a Transaction That Cannot Be Voided

If you had originally sent this Cancel it by using this

transaction... transaction...

Capture Transactions Credit Transactions

Sale Transactions Credit Transactions

Credit Transactions Sale Transactions

Force Capture Transactions Credit Transactions

3.3.39.1 Void Request

The Void request references the <cnpTxnId> of the previously approved transaction. You must structure
a Void request as follows.
<void id = "Void Id" reportGroup="iQ Report Group">
<cnpTxnId>Transaction Id</cnpTxnId>
<processingInstructions>
</void>

Example: Online Void Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<void id="1" reportGroup="Void Division">
<cnpTxnId>345454444</cnpTxnId>
</void>
</cnpOnlineRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

320
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

3.3.39.2 Void Response

The Void response has the following structure.

<voidResponse id="Void Id" reportGroup="iQ Report Group">
<cnpTxnId>Transaction Id</cnpTxnId>
<response>Response Code</response>
<responseTime>Date and Time in GMT</responseTime>
<postDate>Date of Posting</postDate>
<message>Response Message</message>
<location>Processing Platform Location</location>
<recyclingResponse> (May be included if halting recycling.)
</voidResponse>

Example: Online Void Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<voidResponse id="1" reportGroup="Void Division">
<cnpTxnId>1100026202</cnpTxnId>
<response>000</response>
<responseTime>2017-06-16T19:43:38</responseTime>
<postDate>2017-06-16</postDate>
<message>Approved</message>
</voidResponse>
</cnpOnlineResponse>

Example: Online Void Response with Recycling Element

When you use a Void transaction to halt recycling, the response may include the recycling element.
(see Using Void to Halt Recycling Engine on page 78).
<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<voidResponse id="1" reportGroup="Void Division">
<cnpTxnId>1100026202333456789</cnpTxnId>
<response>000</response>
<responseTime>2017-06-16T19:43:38</responseTime>
<postDate>2017-06-16</postDate>
<message>Approved</message>
<recyclingResponse>
<creditCnpTnxId>1234567890123456789</creditCnpTnxId>
</recyclingResponse>
</voidResponse>
</cnpOnlineResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

321
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Transaction Examples

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

322
© 2020 FIS and/or its affiliates. All rights reserved.
 4
cnpAPI Elements

This chapter provides definitions for the elements and attributes used by the cnpAPI. This information is
intended to be used in combination with the various cnpAPI schema files to assist you as you build the
code necessary to submit transactions to our transaction processing systems. Each section defines a
particular element, its relationship to other elements (parents and children), as well as any attributes
associated with the element.
For additional information on the structure of cnpAPI requests and responses using these elements, as
well as XML examples, please refer to Chapter 3, "cnpAPI Transaction Examples".
The XML elements defined in this chapter are listed alphabetically.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

323
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.1 accNum

The accNum element is a required child of the echeck, originalAccountInfo, and

newAccountInfo elements defining the account number of the Direct Debit account.

IMPORTANT: Be sure to submit the exact value without stripping or padding.

Type = String; minLength = N/A; maxLength = 17

Parent Elements:
echeck, newAccountInfo, originalAccountInfo, accountInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

324
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.2 accountInfo

The accountInfo element is a required child of the submerchantCredit, submerchantDebit,

vendorCredit, and vendorDebit transactions. It contains child elements used to provide details
concerning the Sub-merchant account. When submitting Batch transactions, you can use the
ctxPaymentInformation element to provide descriptions of the payment(s).

Parent Elements:
submerchantCredit, submerchantDebit, vendorCredit, vendorDebit

Attributes:
None

Child Elements:
Required: accType, accNum, routingNum
Optional: ccdPaymentInformation
Optional (Batch Only): ctxPaymentInformation

NOTE: Although shown as an optional element in the schema, do not use the checkNum element.

Example: accountInfo Structure for Online Transactions

<accountInfo>
<accType>Account Type Abbreviation</accType>
<accNum>Account Number</accNum>
<routingNum>Routing Number</routingNum>
<ccdPaymentInformation>Payment Description</ccdPaymentInformation>
</accountInfo>

Example: accountInfo Structure for Batch Transactions

<accountInfo>
<accType>Account Type Abbreviation</accType>
<accNum>Account Number</accNum>
<routingNum>Routing Number</routingNum>
<ccdPaymentInformation>Payment Description</ccdPaymentInformation>
<ctxPaymentInformation>
<ctxPaymentDetail>Payment Description 1</ctxPaymentDetail>
<ctxPaymentDetail>Payment Description 2</ctxPaymentDetail>
</ctxPaymentInformation>
</accountInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

325
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.3 accountInformation

The accountInformation element is an optional child of the authorizationResponse and

saleResponse elements. It contains two children that define the card type and account number.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None

Child Elements:
Required: type
Optional: number

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

326
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.4 accountLogin

The accountLogin element is an optional child of the fraudCheck element defining the account login
name. This is an additional data point you can submit to enhance the fraud threat assessment.
Type = String; minLength = N/A; maxLength = 255

Parent Elements:
fraudCheck

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

327
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.5 accountNumber

The accountNumber element is a required child of the registerTokenRequest element defining the
account number for which you are requesting a token. It is also an optional child of the
virtualGiftCardResponse element, where it defines the account number of the requested Virtual Gift
Card.
Type = String; minLength = 13; maxLength = 25

Parent Elements:
registerTokenRequest, virtualGiftCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

328
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.6 accountNumberLength

The accountNumberLength element is a required child of the virtualGiftCard element defining the
requested length of the virtual Gift Card number you are requesting.

NOTE: In an early iteration of schema V8.22 issued in September of 2013 this element was defined
as an optional child of the virtualGiftCard element. If you coded to the earlier version, be
aware that this element is now required. If you do not include this element, the transaction will fail
XML validation.

Type = Integer; Allowed Values between 13 and 25 inclusive.

NOTE: Although the schema defines the allowed values as any integer between 13 and 25
inclusive, it this time you can only use a value of either 16 or 19.

Parent Elements:
virtualGiftCard

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

329
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.7 accountPasshash

The accountPasshash element is an optional child of the fraudCheck element defining the SHA-2
hash of the password in hexadecimal format. Depending on the hash algorithm, the value must be either
128, 96, 64, or 56 characters.
Type = String; minLength = 56; maxLength = 128

Parent Elements:
fraudCheck

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

330
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.8 accountRangeId

The accountRangeId element is an optional child of both the enhancedAuthResponse and

registerTokenResponse elements. It is a Worldpay assigned value representing the account range
of the card used in the transaction. You can use the value to correlate various data points across card
types and issuers.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
registerTokenResponse, enhancedAuthResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

331
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.9 accountUpdate

The accountUpdate element is the parent element for all Account Updater request transactions. You
can use this only with Batch transactions.

Parent Elements:
batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (all Required)

orderId, cardOrToken (allows the substitution of either the card or token elements)

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

332
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.10 accountUpdateFileRequestData

The accountUpdateFileRequestData element is a child of the RFRRequest element, required when

requesting the response file for an (legacy) Account Updater submission.

Parent Elements:
RFRRequest

Attributes:
None

Child Elements:
Required: merchantId
Optional: postDay

Example: accountUpdateFileRequestData Structure

<accountUpdateFileRequestData>
<merchantId>Merchant ID</merchantId>
<postDay>Post Date</postDay>
</accountUpdateFileRequestData>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

333
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.11 accountUpdater

The accountUpdater element is an optional child of the authorizationResponse,

captureResponse, echeckSalesResponse, echeckcreditResponse,
echeckVerificationResponse, forceCaptureResponse, and saleResponse elements. This
element is included in the response messages when the submitted account information has changed.
In the case of Direct Debit accounts, the system automatically updates the information sent to the ACH
network and includes the original and updated information in the response. Similarly, if you use the
Account Updater service (for credit cards), the system automatically repairs the card information sent to
the card networks and depending upon the option you select, can return the info to you.

Parent Elements:
authorizationResponse, captureResponse, forceCaptureResponse, echeckCreditResponse,
echeckRedepositResponse, echeckSalesResponse, saleResponse

Attributes:
None

Child Elements:
accountUpdateSource, extendedCardResponse, newAccountInfo, newCardInfo, newCardTokenInfo,
newTokenInfo, originalAccountInfo, originalCardInfo, originalCardTokenInfo, originalTokenInfo

IMPORTANT: When using Account Updater (any variation), you must always code to receive the
extendedCardResponse element and its children. Worldpay always returns this information
whenever applicable regardless of whether you receive other account updater information in the
transaction response message.

Example: accountUpdater Structure - Credit Cards without extendedCardResponse

<accountUpdater>
<originalCardInfo>
<type>Card Type</type>
<number>Old Account Number</number>
<expDate>Old Expiration Date</expDate>
</originalCardInfo>
<newCardInfo>
<type>Card Type</type>
<number>New Account Number</number>
<expDate>New Expiration Date</expDate>
</newCardInfo>
<accountUpdateSource>R or N</accountUpdateSource>
</accountUpdater>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

334
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: accountUpdater Structure - Credit Cards with extendedCardResponse

<accountUpdater>
<originalCardInfo>
<type>Card Type</type>
<number>Old Account Number</number>
<expDate>Old Expiration Date</expDate>
</originalCardInfo>
<newCardInfo>
<type>Card Type</type>
<number>New Account Number</number>
<expDate>New Expiration Date</expDate>
</newCardInfo>
<extendedCardResponse>
<message>Code Description</message>
<code>Either 501 or 504</code>
</extendedCardResponse>
<accountUpdateSource>R or N</accountUpdateSource>
</accountUpdater>

Example: accountUpdater Structure - Credit Cards only extendedCardResponse

<accountUpdater>
<extendedCardResponse>
<message>Code Description</message>
<code>Either 501 or 504</code>
</extendedCardResponse>
<accountUpdateSource>R or N</accountUpdateSource>
</accountUpdater>

Example: accountUpdater Structure - Credit Cards (tokenized Merchant)

NOTE: This structure can also include the <extendedCardResponse> element.

<accountUpdater>
<originalCardTokenInfo>
<cnpToken>Old Token</cnpToken>
<type>Card Type</type>
<expDate>Old Expiration Date</expDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

335
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<bin>Old Card BIN</bin>

</originalCardTokenInfo>
<newCardTokenInfo>
<cnpToken>New Token</cnpToken>
<type>Card Type</type>
<expDate>New Expiration Date</expDate>
<bin>New Card BIN</bin>
</newCardTokenInfo>
<accountUpdateSource>R or N</accountUpdateSource>
</accountUpdater>

Example: accountUpdater Structure - Direct Debit (for non-Tokenized Merchant)

<accountUpdater>
<originalAccountInfo>
<accType>Original Account Type</accType>
<accNum>Original Account Number</accNum>
<routingNum>Original Routing Number</routingNum>
</originalAccountInfo>
<newAccountInfo>
<accType>New Account Type</accType>
<accNum>New Account Number</accNum>
<routingNum>New Routing Number</routingNum>
</newAccountInfo>
</accountUpdateFileRequestData>

Example: accountUpdater Structure - Direct Debit (for Tokenized Merchant)

<accountUpdater>
<originalTokenInfo>
<accType>Original Account Type</accType>
<cnpToken>Original Token</cnpToken>
<routingNum>Original Routing Number</routingNum>
</originalTokenInfo>
<newTokenInfo>
<accType>New Account Type</accType>
<cnpToken>New Token</cnpToken>
<routingNum>New Routing Number</routingNum>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

336
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

</newTokenInfo>
</accountUpdateFileRequestData>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

337
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.12 accountUpdateResponse

The accountUpdaterResponse element is the parent element for all Account Update responses
transactions. You can use this only with Batch transactions.

Parent Elements:
batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
accountUpdate transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
accountUpdate transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
accountUpdate transaction.
minLength = 1 maxLength = 25

Child Elements: (Required)

cnpTxnId, orderId, response, responseTime, message
Child Elements: (Optional)
updatedCard, originalCard, originalToken, updatedToken

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

338
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.13 accountUpdateSource

The accountUpdateSource element is an optional child of the accountUpdater element used to

indicate if the source of the update information is real-time (R) or non-real-time/update from cache (N).
Type = String (Enum); Enumerations = R or N

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

339
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.14 accType

The accType element is a required child of the echeck, originalAccountInfo, and

newAccountInfo elements defining the type of Direct Debit account used in the transaction.
Type = Choice (Enum); Enumerations = Checking, Savings, Corporate, or Corp Savings

NOTE: Use Corporate for Corporate Checking accounts.

Parent Elements:
echeck, newAccountInfo, originalAccountInfo, originalTokenInfo, newTokenInfo, accountInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

340
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.15 actionReason

The actionReason element is an optional child of the authReversal element defining if the reversal is
due to suspected fraud.
Type = String (Enum); Enumerations = SUSPECT_FRAUD

NOTE: When you include this optional element in an authReversal transaction, the information
will be forwarded to Mastercard as part of the Mastercard eCommerce Fraud Alert program.
When you include this optional element in an credit transaction, the system uses the information
to track potentially fraudulent transactions for future analysis.

Parent Elements:
authReversal, credit

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

341
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.16 activate

The activate element is the parent element for the transaction type that activates a Gift Card.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

orderId, amount, orderSource, card, virtualGiftCard

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

342
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.17 activateResponse

The activateResponse element is the parent element for information returned to you in response to an
activate transaction.You can use this element in either Online or Batch transactions.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Activate transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Activate transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Activate transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: postDate, fraudResult, giftCardResponse, virtualGiftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

343
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.18 activateReversal

The activateReversal element is the parent element for the transaction type that reverses the
activation of a Gift Card.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId, virtualGiftCardBin

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

344
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.19 activateReversalResponse

The activateReversalResponse element is the parent element for information returned to you in
response to an activateReversal transaction. You can use this element in either Online or Batch
transactions.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Activate Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Activate Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Activate Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

345
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.20 active

The active element is an optional child of both the createPlan and updatePlan elements. You use
this flag to activate/deactivate a Plan. When you deactivate a Plan, you can no longer reference that Plan
for use with subscriptions. Existing subscriptions making use of the deactivated Plan will continue to use
the Plan until either modified or completed. You can also reactivate a deactivated Plan by updating the
Plan and setting the active flag to true.
Type = Boolean; Valid Values = true or false

Parent Elements:
createPlan, updatePlan

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

346
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.21 addOnCode

The addOnCode element is the identifier of a defined add on charge to a subscription. You use this
element when creating, updating, and deleting an Add On applied to a subscription.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
createAddOn, updateAddOn, deleteAddOn

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

347
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.22 addressLine1, addressLine2, addressLine3

The elements addressLine1, addressLine2, and addressLine3 define the address information in
both the billToAddress and shipToAddress elements.
Type = String; minLength = N/A; maxLength = 35

Parent Elements:
billToAddress, shipToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

348
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.23 advancedAVSResult

The advancedAVSResult element is an optional child element of the fraudResult element. It defines
the American Express Advanced AVS response codes that can be returned as verification of information
supplied in the <phone> and/or <email> child elements of the <billToAddress> element. For a list of
possible values, please refer to AAVS Response Codes on page 860.

NOTE: You must be specifically enabled to use the Advanced AVS feature. Please consult your
Relationship Manager for additional information.

Type = String; minLength = N/A; maxLength = 3

Parent Elements:
fraudResult

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

349
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.24 advancedFraudChecks

The advancedFraudChecks element is an optional child of both the authorization and sale
elements and a required child of the fraudCheck element.

Parent Elements:
authorization, sale, fraudCheck

Attributes:
None
Child Elements:
threatMetrixSessionId, webSessionId, customAttribute1 through customAttribute5

NOTE: If you use V12.3 or above, you must use the webSessionId to provide the Id value, not
the threatMetrixSessionId element.

Example: advancedFraudChecks Structure with threatMetrixId

<advancedFraudChecks>
<threatMetrixSessionId>Session Id for Fraud Check</threatMetrixSessionId>
<customAttribute1>Some attribute passed for Fraud Check</customAttribute1>
<customAttribute2>Some attribute passed for Fraud Check</customAttribute2>
<customAttribute3>Some attribute passed for Fraud Check</customAttribute3>
<customAttribute4>Some attribute passed for Fraud Check</customAttribute4>
<customAttribute5>Some attribute passed for Fraud Check</customAttribute5>
</advancedFraudChecks>

Example: advancedFraudChecks Structure with webSessionId

<advancedFraudChecks>
<webSessionId>Session Id for Fraud Check</webSessionId>
<customAttribute1>Some attribute passed for Fraud Check</customAttribute1>
<customAttribute2>Some attribute passed for Fraud Check</customAttribute2>
<customAttribute3>Some attribute passed for Fraud Check</customAttribute3>
<customAttribute4>Some attribute passed for Fraud Check</customAttribute4>
<customAttribute5>Some attribute passed for Fraud Check</customAttribute5>
</advancedFraudChecks>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

350
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.25 advancedFraudResults

The advancedFraudResults element is an optional child of both the fraudResult and the
fraudCheckResponse elements. Child elements return the results of advanced fraud checks performed
by ThreatMetrix, as well as a list of the rules triggered from the ThreatMetrix (merchant) Policy.

Parent Elements:
fraudResult, fraudCheckResponse

Attributes:
None
Child Elements: (Optional)

NOTE: The elements, deviceReputationScore and triggeredRule, alway appear, unless

deviceReviewStatus is unavailable.

deviceReviewStatus, deviceReputationScore, triggeredRule

Example: advancedFraudChecks Structure

<advancedFraudResults>
<deviceReviewStatus>pass, fail, review, or unavailable</deviceReviewStatus>
<deviceReputationScore>Score Returned from ThreatMetix</deviceReputationScore>
<triggeredRule>Triggered Rule #1</triggeredRule>
.
.
.
<triggeredRule>Triggered Rule #N</triggeredRule>
</advancedFraudResults>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

351
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.26 affiliate

The affiliate element is an optional child element of the merchantData element. You can use it to
track transactions associated with various affiliate organizations.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
merchantData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

352
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.27 affluence

The affluence element is an optional child of the enhancedAuthResponse element and defines
whether the card used falls into one of the two defined affluent categories. If the card does not meet the
definition of either category, the system does not return the affluence element.
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
enhancedAuthResponse

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

MASS AFFLUENT Returned for certain Visa and Mastercard cards indicating high income
customers (>100K annual income).

AFFLUENT Returned for certain Visa and Mastercard cards indicating high income
customers with high spending patterns (>100K annual income and
>40K in card usage).

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

353
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.28 allowPartialAuth

The allowPartialAuth element is an optional child of both Authorization and Sale transactions, which
allows you to specify whether to authorize a partial amount if the entire requested authorization amount
exceeds available credit/balance.

NOTE: If you settle in a currency other than US or Canada, you cannot use partial authorizations.
When submitting transactions for private label gift cards (card type of GC), the use of partial
authorizations is determined by a setting in the Merchant Profile (on or off globally). This flag has no
effect.

Type = Boolean; Valid Values = true or false

Parent Elements:
authorization, sale

Attributes:
None
Child Elements:
None

NOTE: For a Sale transaction, the deposit will be for the partial amount.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

354
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.29 amount

The amount element is a child of several elements. When used in a payment transaction this element
defines the amount of the transaction. When amount is a child of the subscription element, it defines
the amount of the recurring payment. As a child of the activate, load, or unload transactions,
amount defines the initial value of a newly activated gift Card, the amount loaded onto a reloadable Gift
Card, or the amount unloaded from a Gift Card, respectively. When used in an Instruction-Based Dynamic
Payout transaction type, it specifies the amount of funds to transfer. Supply the value in cents without a
decimal point. For example, a value of 1995 signifies $19.95.

NOTE: For the following currencies, the value you submit is the amount without implied decimal:
Burundian Franc, Chilean Peso, Comoro Franc, Djibouti Franc, Guinea Franc, Iceland Krona,
Japanese Yen, South Korean Won, Vanuatu Vatu, Paraguayan Guarani, Rawanda Franc,
Vietnamese Dong, Uganda Shilling, CFA Franc BEAC, CFA Franc BCEAO, and CFP Franc.
For example, if the currency is Japanese Yen, entering 2000 means 2000 Yen, NOT 20.00 Yen.

Type = Integer; totalDigits = 12

Parent Elements:
The amount element is a required child of each of the following Parent Elements: activate, authorization,
credit (required if original transaction was not processed by Worldpay), captureGivenAuth, echeckCredit
(required if original transaction was not processed by Worldpay), echeckSale, echeckVerification,
forceCapture, fraudCheck, load, sale, unload
This element is also a required child of the following Instruction-Based Dynamic Payout transaction types:
payFacCredit, payFacDebit, physicalCheckCredit, physicalCheckDebit, reserveCredit, reserveDebit,
submerchantCredit, submerchantDebit, vendorCredit, vendorDebit, fastAccessFunding
The amount element is an optional child of each of the following Parent Elements: authReversal, capture,
credit, echeckCredit, subscription

NOTE: For all cases where the amount element is optional, except when a child of the
subscription element, if you do not specify a value, the system uses the entire amount from the
referenced (by cnpTxnId) transaction. When amount is a child of the subscription element, if
you do not specify a value, the amount defaults to the value defined in the referenced recurring plan
(planCode element).

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

355
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.30 androidpayResponse

The androidpayResponse element is an optional child of several transaction types and is returned in
response messages, when the orderSource in the request is androidpay.

Parent Elements:
authorizationResponse, registerTokenResponse, saleResponse

Attributes:
None

Child Elements (all optional):

cryptogram, expMonth, expYear, eciIndicator

Example: androidpayResponse Structure

<androidpayResponse>
<cryptogram>Payment Cryptogram</cryptogram>
<expMonth>Expiration Month</expMonth>
<expYear>Expiration Year</expYear>
<eciIndicator>eCommerece Indicator</eciIndicator>
</androidpayResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

356
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.31 applepay

The applepay element is an optional child of several transaction types and takes the place of the card
element in Apple Pay transaction where the merchant does not decrypt the (Apple Pay)
PKPaymentToken prior to submitting the transaction. It contains child elements for the component parts
of the PKPaymentToken.

Parent Elements:
authorization, registerTokenRequest, sale

Attributes:
None

Child Elements (all required):

data, header, signature, version

Example: applepay Structure

<applepay>
<data>User Name</data>
<header>
<applicationData>Base64 Hash of App Data Property</applicationData>
<ephemeralPublicKey>Base64 Encoded Ephemeral Public Key</ephemeralPublicKey>
<publicKeyHash>Base64 Hash of Public Merchant Key Cert</publicKeyHash>
<transactionId>Hex Transaction Id</transactionId>
</header>
<signature>Signature of Payment and Header Data</signature>
<version>Payment Token Version Info</version>
</applepay>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

357
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.32 applepayResponse

The applepayResponse element is an optional child of several transaction types and is returned in
response messages, when the request includes the applepay element.

Parent Elements:
authorizationResponse, registerTokenResponse, saleResponse

Attributes:
None

Child Elements:
applicationPrimaryAccountNumber, applicationExpirationDate, currencyCode, transactionAmount,
cardholderName, deviceManufacturerIdentifier, paymentDataType, onlinePaymentCryptogram,
eciIndicator

Example: applepayResponse Structure

<applepayResponse>
<applicationPrimaryAccountNumber>App PAN</applicationPrimaryAccountNumber>
<applicationExpirationDate>App PAN Exp Date</applicationExpirationDate>
<currencyCode>Currency Code</currencyCode>
<transactionAmount>Amount of Transaction</transactionAmount>
<cardholderName>Name of cardholder</cardholderName>
<deviceManufacturerIdentifier>Id of Device Mfr</deviceManufacturerIdentifier>
<paymentDataType>Type of Payment Data</paymentDataType>
<onlinePaymentCryptogram>Payment Cryptogram</onlinePaymentCryptogram>
<eciIndicator>eCommerece Indicator</eciIndicator>
</applepayResponse>

IMPORTANT: The system never returns the applicationPrimaryAccountNumber element in

a registerTokenresponse message, since this transaction type includes a token replacing the
application PAN.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

358
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.33 applicationData

The applicationData element is an optional child of the header element and provides the SHA-256
hash, hex encoded string of the original PKPaymentRequest of the Apple Pay transaction.
Type = Hex Encoded String; minLength = N/A; maxLength = 10000

Parent Elements:
header

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

359
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.34 applicationExpirationDate

The applicationExpirationDate element is an optional child of the applepayResponse element

and defines expiration date of the application primary account number.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
applepayResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

360
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.35 applicationPrimaryAccountNumber

The applicationPrimaryAccountNumber element is an optional child of the applepayResponse

element and defines the primary account number associated with the application.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
applepayResponse

Attributes:
None

Child Elements:
None

IMPORTANT: The system never returns the applicationPrimaryAccountNumber element

(child of the applepayResponse element) in a registerTokenresponse message, since this
transaction type includes a token replacing the application PAN.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

361
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.36 approvedAmount

The approvedAmount element defines the dollar amount of the approval. It appears in an authorization
or sale response only if the allowPartialAuth element is set to true in the request transaction. It can
also appear as the child of a deactivateResponse message where it specifies the value of the Gift Card
prior to deactivation.
Type = Integer; totalDigits = 12

Parent Elements:
authorizationResponse, saleResponse, deactivateResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

362
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.37 authAmount

The authAmount element is an optional child of the authInformation element and is used to define the
dollar amount of the authorization for Capture Given Auth transactions.
Type = Integer; totalDigits = 8

Parent Elements:
authInformation

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

363
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.38 authCode

The authCode element is an optional child of both the authorizationResponse and saleResponse
elements. It is also a required child of the authInformation element (used in captureGivenAuth
transactions), where it specifies the authorization code from the associated Authorization or Sale
transaction.
Type = String; minLength = N/A; maxLength = 6

Parent Elements:
authInformation, authorizationResponse, saleResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

364
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.39 authDate

The authDate element is a required child of the authInformation element and defines the date of the
associated Authorization transaction.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
authInformation

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

365
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.40 authenticatedByMerchant

The authenticatedByMerchant element is an optional child element of the

cardholderAuthentication element. This element indicates whether or not the customer has logged
in to a secure web site or has been authenticated by the call center ANI.
Type = Boolean; Valid Values = true or false

Parent Elements:
cardholderAuthentication

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

366
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.41 authentication

The authentication element is a required element of both the cnpOnlineRequest and the
batchRequest elements. It contains child elements used to authenticate that the XML message is from
a valid user.

NOTE: The authentication element and its child elements, user and password, are used to
identify the merchant submitting transactions. They do not provide other access to platform or to the
iQ reporting system.

Parent Elements:
cnpOnlineRequest, cnpRequest

Attributes:
None

Child Elements:
Required: user, password

Example: authentication Structure

<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

367
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.42 authenticationProtocolVersion

The authenticationProtocolVersion element is an optional child element of the fraudCheck

element. You use it to define if the transaction uses 3DS1 or 3DS2. The value defaults to 1, so you can
omit the element if you use 3DS1, but if you use 3DS2, you must include the element with a value of 2.
Type = Enum; Allowed Values = 1 or 2

NOTE: Currently, the US eCom platform does not support 3DS2. Please speak to your Relationship
Manager for additional information about 3DS2 support.

Parent Elements:
cardholderAuthentication

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

368
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.43 authenticationResult

The authenticationResult element is an optional child element of the fraudResult element. It

defines the 3DS results from either Verified by Visa, Mastercard SecureCode, American Express
SafeKey, or Discover ProtectBuy. For a list of possible values, please refer to 3DS Authentication Result
Codes on page 857.
Type = String; minLength = N/A; maxLength = 1

Parent Elements:
fraudResult

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

369
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.44 authenticationTransactionId

The authenticationTransactionId element is an optional child of the

cardholderAuthentication element. This element defines the Verified by Visa Transaction Id or the
Visa TAVV (Token Authentication Verification Value). This element is not used for Discover ProtectBuy or
American Express SafeKey transactions.
You must include this element for Visa transactions, when the orderSource element is set to
3dsAuthenticated.
Type = String; minLength = N/A; maxLength = 36

Parent Elements:
cardholderAuthentication

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

370
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.45 authenticationValue

The authenticationValue element is an optional child of the cardholderAuthentication

element. This element defines either the Visa CAVV value (fixed length 28 characters), the Mastercard
UCAF value (variable length up to 32 characters), or the American Express SafeKey authentication value.
You must include this element for Visa, Mastercard and American Express transactions, when the
orderSource element is set to 3dsAuthenticated, as well as Mastercard and American Express
transactions if the orderSource element is set to 3dsAttempted.
You also use this element to sent Worldpay the Apple Pay cryptogram if you decrypt the Apple Pay
PKPaymentToken (see Merchant Decryption of Apple Pay PKPaymentToken on page 55).

NOTE: The Apple Pay cryptogram is already BASE64 encoded. Do not double encode the
cryptogram.

Type = Base 64 Encoded String; minLength = N/A; maxLength = 56

Parent Elements:
cardholderAuthentication

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

371
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.46 authInformation

The authInformation element is a required child of the captureGivenAuth element. It contains

child elements used to provide details concerning the external (to the systems) Authorization.

Parent Elements:
captureGivenAuth

Attributes:
None

Child Elements:
Required: authDate, authCode
Optional: fraudResult, authAmount

Example: authInformation Structure

<authInformation>
<authDate>Auth Date</authDate>
<authCode>Approval Code</authCode>
<fraudResult>
<avsResult>AVS Verification Result Code</avsResult>
<cardValidationResult>Validation Result Code</cardValidationResult>
<authenticationResult>Verified by Visa Result Code</authenticationResult>
</fraudResult>
<authAmount>Amount of Authorization</authAmount>
</authInformation>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

372
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.47 authorization

The authorization element is the parent element for all Authorization transactions. You can use this
element in either Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, amount, orderSource, (choice of) card, paypal, paypage, mpos, token, or applepay,
cardholderAuthentication

NOTE: The cardholderAuthentication child element is required only for 3-D Secure transactions.

Optional: customerInfo, billToAddress, shipToAddress, processingInstructions, pos, customBilling,

taxType, enhancedData, allowPartialAuth, healthcareIIAS, merchantData, recyclingRequest,
fraudFilterOverride, surchargeAmount, debtRepayment, recurringRequest, advancedFraudChecks,
secondaryAmount, wallet, processingType, filtering, originalNetworkTransactionId,
originalTransactionAmount, lodgingInfo, pinlessDebitRequest, skipRealtimeAU, merchantCategoryCode

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

373
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.48 authorizationResponse

The authorizationResponse element is the parent element for information returned to you in
response to an Authorization transaction. It can be a child of either a cnpOnlineResponse element or a
batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Authorization transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Authorization transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Authorization transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, orderId, response, responseTime, message
Optional: postDate, cardProductId (see Note below), authCode, authorizationResponseSubCode (see
Note below), approvedAmount, accountInformation, fraudResult, tokenResponse,
enhancedAuthResponse, accountUpdater, recyclingResponse, recurringResponse, giftCardResponse,
applepayResponse, cardSuffix, androidpayResponse, networkTransactionId,
paymentAccountReferenceNumber, pinlessDebitResponse, location

NOTE: The postDate child element is returned only in responses to Online transactions.
The cardProductId element returns a raw code referencing the card type. Please consult your
Relationship Manager for additional information.
The authorizationResponseSubCode element is not used at this time.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

374
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.49 authReversal

The authReversal element is the parent element for all Authorization Reversal transactions. You can
use this element in either Online or Batch transactions. Also see Notes on the Use of Authorization
Reversal Transactions on page 71. Also, if you use the Recycling Engine, you can use the
authReversal transaction to halt the recycling of an authorization transaction.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId
Optional: amount, actionReason, payPalNotes, surchargeAmount

NOTE: If you do not specify an amount child element, the system reverses the full amount from the
associated Authorization transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

375
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.50 authReversalResponse

The authReversalResponse element is the parent element for information returned to you in response
to an Auth Reversal transaction. It can be a child of either a cnpOnlineResponse element or a
batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Authorization Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Authorization Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Authorization Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

376
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.51 availableBalance

The availableBalance element is a required child element of the fundingSource element and an
optional child of the giftCardResponse element. It defines the outstanding available balance on the
submitted prepaid or Gift Card. If the balance can not be determined, the element returns, “Not Available.”
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
fundingSource, giftCardResponse

Attributes:
None

Child Elements:
None

NOTE: The fundingSource element and its child elements, type and availableBalance are
associated with the Insights features (see Issuer Insights on page 24.)
Please consult your Relationship Manager for additional information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

377
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.52 avsResult

The avsResult element is an optional child element of the fraudResult element. It defines the
Address Verification response code returned by the networks. For a list of possible values, please refer to
AVS Response Codes on page 859.
Type = String; minLength = N/A; maxLength = 2

Parent Elements:
fraudResult

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

378
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.53 balanceInquiry

The balanceInquiry element is the parent element for the transaction type that queries the available
balance of a Gift Card.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (all Required)

orderId, orderSource, card

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

379
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.54 balanceInquiryResponse

The balanceInquiryResponse element is the parent element for information returned to you in
response to a balanceInquiry transaction. It can be a child of either a cnpOnlineResponse element
or a batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Balance Inquiry transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Balance Inquiry transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Balance Inquiry transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, orderId, response, responseTime, message
Optional: postDate, fraudResult, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

380
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.55 batchRequest

This is the root element for all cnpAPI Batch requests.

Parent Elements:
cnpRequest

Attributes:

NOTE: Include the count and amount attributes for all transaction types included in the Batch. For
example if you submit one Sale transaction of $10, include numSales="1" and saleAmount="1000".
You must always include an amount, if you include a count. Do not include corresponding attributes,
if the Batch does not include the transaction type.

Attribute Name Type Required? Description

id String No A unique string to identify this batchRequest

within the system.
minLength = N/A maxLength = 25

numAuths Integer No Defines the total count of Authorization

transactions in the batchRequest.
minLength = N/A maxLength = N/A

authAmount Integer No Defines the total dollar amount of Authorization

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numAuthReversals Integer No Defines the total count of AuthReversal

transactions in the batchRequest.
minLength = N/A maxLength = N/A

authReversalAmount Integer No Defines the total dollar amount of AuthReversal

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numGiftCardAuthReversa Integer No Defines the total count of giftCardAuthReversal

ls transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

381
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

giftCardAuthReversalOrig Integer No Defines the total dollar amount of

inalAmount giftCardAuthReversal transactions in the
batchRequest. The decimal point is implied.
For example, you enter $25.00 as 2500.
totalDigits = 10

numCaptures Integer No Defines the total count of Capture transactions in

the batchRequest.
minLength = N/A maxLength = N/A

captureAmount Integer No Defines the total dollar amount of Capture

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numGiftCardCaptures Integer No Defines the total count of giftCardCapture

transactions in the batchRequest.
minLength = N/A maxLength = N/A

giftCardCaptureAmount Integer No Defines the total dollar amount of

giftCardCapture transactions in the
batchRequest. The decimal point is implied.
For example, you enter $25.00 as 2500.
totalDigits = 10

numCredits Integer No Defines the total count of Credit transactions in

the batchRequest.
minLength = N/A maxLength = N/A

creditAmount Integer No Defines the total dollar amount of Credit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numGiftCardCredits Integer No Defines the total count of giftCardCredit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

giftCardCreditAmount Integer No Defines the total dollar amount of giftCardCredit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numForceCaptures Integer No Defines the total count of Force Capture

transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

382
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

forceCaptureAmount Integer No Defines the total dollar amount of Force Capture

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numSales Integer No Defines the total count of Sale transactions in

the batchRequest.
minLength = N/A maxLength = N/A

saleAmount Integer No Defines the total dollar amount of Sale

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numCaptureGivenAuths Integer No Defines the total count of Capture Given Auth

transactions in the batchRequest.
minLength = N/A maxLength = N/A

captureGivenAuthAmount Integer No Defines the total dollar amount of Capture Given

Auth transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

numEcheckSales Integer No Defines the total count of eCheck Sale

transactions in the batchRequest.
minLength = N/A maxLength = N/A

echeckSalesAmount Integer No Defines the total dollar amount of eCheck Sale

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numEcheckCredit Integer No Defines the total count of eCheck Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

echeckCreditAmount Integer No Defines the total dollar amount of eCheck Credit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

numEcheckVerification Integer No Defines the total count of eCheck Verification

transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

383
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

echeckVerificationAmoun Integer No Defines the total dollar amount of eCheck

t Verification transactions in the batchRequest.
The decimal point is implied. For example, you
enter $25.00 as 2500.
totalDigits = 10

numEcheckRedeposit Integer No Defines the total count of eCheck Redeposit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numEcheckPreNoteSale Integer No Defines the total count of eCheck Prenotification

Sale transactions in the batchRequest.
minLength = N/A maxLength = N/A

numEcheckPreNoteCredi Integer No Defines the total count of eCheck Prenotification

t Credit transactions in the batchRequest.
minLength = N/A maxLength = N/A

numAccountUpdates Integer No Defines the total count of Account Update

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numTokenRegistrations Integer No Defines the total count of Token Registration

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numUpdateCardValidatio Integer No Defines the total count of Update Card

nNumOnTokens Validation Number request transactions in the
batchRequest.
minLength = N/A maxLength = N/A

numCancelSubscriptions Integer No Defines the total count of Cancel Subscription

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numUpdateSubscriptions Integer No Defines the total count of Update Subscription

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numCreatePlans Integer No Defines the total count of Create Plan

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numUpdatePlans Integer No Defines the total count of Update Plan

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numActivates Integer No Defines the total count of (Gift Card) Activate

transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

384
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

numDeactivates Integer No Defines the total count of (Gift Card) Deactivate

transactions in the batchRequest.
minLength = N/A maxLength = N/A

activateAmount Integer No Defines the total dollar amount of (Gift Card)

Activate transactions in the batchRequest.
The decimal point is implied. For example, you
enter $25.00 as 2500.
totalDigits = 10

numLoads Integer No Defines the total count of (Gift Card) Load

transactions in the batchRequest.
minLength = N/A maxLength = N/A

loadAmount Integer No Defines the total dollar amount of (Gift Card)

Load transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

numUnloads Integer No Defines the total count of (Gift Card) Unload

transactions in the batchRequest.
minLength = N/A maxLength = N/A

unloadAmount Integer No Defines the total dollar amount of (Gift Card)

Unload transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

numBalanceInquirys Integer No Defines the total count of (Gift Card) Balance

Inquiry transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPayFacCredit Integer No Defines the total count of PayFac Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPayFacDebit Integer No Defines the total count of PayFac Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numSubmerchantCredit Integer No Defines the total count of Submerchant Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numSubmerchantDebit Integer No Defines the total count of Submerchant Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

385
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

numReserveCredit Integer No Defines the total count of Reserve Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numReserveDebit Integer No Defines the total count of Reserve Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numVendorCredit Integer No Defines the total count of Vendor Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numVendorDebit Integer No Defines the total count of Vendor Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPhysicalCheckCredit Integer No Defines the total count of Physical Check Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPhysicalCheckDebit Integer No Defines the total count of Physical Check Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numFundingInstructionVo Integer No Defines the total count of Funding Instruction

id Void transactions in the batchRequest.
minLength = N/A maxLength = N/A

numFastAccessFunding Integer No Defines the total count of Fast Access Funding

Instruction transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPayoutOrgCredit Integer No Defines the total count of Payout Org Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numPayoutOrgDebit Integer No Defines the total count of Payout Org Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numCustomerCredit Integer No Defines the total count of Customer Credit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

numCustomerDebit Integer No Defines the total count of Customer Debit

transactions in the batchRequest.
minLength = N/A maxLength = N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

386
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

numTranslateToLowValu Integer No Defines the total count of HVT to LVT translation

eTokenRequests transactions in the batchRequest.
minLength = N/A maxLength = N/A

payFacCreditAmount Integer No Defines the total dollar amount of PayFac Credit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

payFacDebitAmount Integer No Defines the total dollar amount of PayFac Debit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

submerchantCreditAmou Integer No Defines the total dollar amount of Sub-merchant

nt Credit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

submerchantDebitAmoun Integer No Defines the total dollar amount of Sub-merchant

t Debit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

reserveCreditAmount Integer No Defines the total dollar amount of Reserve Credit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

reserveDebitAmount Integer No Defines the total dollar amount of Reserve Debit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

vendorCreditAmount Integer No Defines the total dollar amount of Vendor Credit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

387
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

vendorDebitAmount Integer No Defines the total dollar amount of Vendor Debit

transactions in the batchRequest. The decimal
point is implied. For example, you enter $25.00
as 2500.
totalDigits = 10

physicalCheckCreditAmo Integer No Defines the total dollar amount of Physical

unt Check Credit transactions in the
batchRequest. The decimal point is implied.
For example, you enter $25.00 as 2500.
totalDigits = 10

physicalCheckDebitAmou Integer No Defines the total dollar amount of Physical

nt Check Debit transactions in the batchRequest.
The decimal point is implied. For example, you
enter $25.00 as 2500.
totalDigits = 10

FastAccessFundingAmou Integer No Defines the total dollar amount of Fast Access

nt Funding transactions in the batchRequest.
The decimal point is implied. For example, you
enter $25.00 as 2500.
totalDigits = 10

payoutOrgCreditAmount Integer No Defines the total dollar amount of Payout Org

Credit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

payoutOrgDebitAmount Integer No Defines the total dollar amount of Payout Org

Debit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

customerCreditAmount Integer No Defines the total dollar amount of Customer

Credit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

customerDebitAmount Integer No Defines the total dollar amount of Customer

Debit transactions in the batchRequest. The
decimal point is implied. For example, you enter
$25.00 as 2500.
totalDigits = 10

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

388
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

merchantId String Yes A unique string to identify the merchant within

the system.
minLength = N/A maxLength = 50
Note: International currencies are supported
on a per merchantId basis.

sameDayFunding Boolean No Used for Dynamic Payout Funding Instructions

only. Set to true to mark this Batch of Funding
Instructions for same day funding. Also, see
Same Day Funding on page 905.

Child Elements:
At least one of the following required: activate, authorization, authReversal, balanceInquiry,
cancelSubscription, capture, captureGivenAuth, createPlan, credit, deactivate, echeckCredit,
echeckPreNoteSale, echeckRedeposit, echeckSale, echeckVerification, fastAccessFunding,
forceCapture, giftCardAuthReversal, giftCardCapture, giftCardCredit, load, registerTokenRequest, sale,
unload, updateCardValidationNumOnToken, updatePlan, updateSubscription, payFacCredit,
customerCredit, customerDebit, payoutOrgCredit, payoutOrgDebit, payFacDebit, reserveCredit,
reserveDebit, submerchantCredit, submerchantDebit, vendorCredit, vendorDebit

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

389
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.56 batchResponse

The batchResponse element is the parent element for information returned to you in response to a
batch you submitted for processing. It is a child of a cnpResponse element.

Parent Elements:
cnpResponse

Attributes:

Attribute Name Type Required? Description

id String No The response returns the same value submitted in the

Batch Request.
minLength = N/A maxLength = 36

cnpBatchId Long Yes A unique value assigned by Worldpay to identify the

batch.
minLength = N/A maxLength = 19

merchantId String Yes The response returns the same value submitted in the
Batch Request.
minLength = 1 maxLength = 50

Child Elements:
Required:accountUpdateResponse, activateResponse, authorizationResponse, authReversalResponse,
captureResponse, captureGivenAuthResponse, createPlanResponse, creditResponse,
deactivateResponse, echeckCreditResponse, echeckPreNoteCreditResponse,
echeckPreNoteSaleResponse, echeckRedepositResponse, echeckSalesResponse,
echeckVerificationResponse,fastAccessFundingResponse, forceCaptureResponse,
giftCardAuthReversalResponse, giftCardCaptureResponse, giftCardCreditResponse, loadResponse,
registerTokenResponse, saleResponse, unloadResponse, updateCardValidationNumOnTokenResponse,
cancelSubscriptionResponse, updatePlanResponse, updateSubscriptionResponse,
payFacCreditResponse, payFacDebitResponse, physicalCheckCreditResponse,
physicalCheckDebitResponse, reserveCreditResponse, reserveDebitResponse,
submerchantCreditResponse, submerchantDebitResponse, vendorCreditResponse,
vendorDebitResponse, customerCreditResponse, customerDebitResponse, payoutOrgCerditResponse,
payoutOrgDebitResponse

NOTE: The batchResponse contains child elements corresponding to the requests submitted in
the batchRequest. For example, if the batchRequest contained 10 authorization and 8
capture transactions, the batchResponse would contain 10 authorizationResponse and 8
captureResponse transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

390
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.57 beginningBalance

The beginningBalance element is an optional child of the giftCardResponse element. It defines the
available balance on the submitted Gift Card prior to the requested operation.

NOTE: Although included in the schema, the beginningBalance, endingBalance, and

cashBackAmount elements are not currently supported.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
giftCardResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

391
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.58 billingDate

The billingDate element is an optional child of the updateSubscription element that defines the
new date for the recurring billing when the scheduled date need to be changed.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
updateSubscription

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

392
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.59 billToAddress

The billToAddress element contains several child elements that define the postal mailing address
(and telephone number) used for billing purposes. It also contains several elements used for the eCheck
verification process.

Parent Elements:
authorization, captureGivenAuth, credit, echeckCredit (required if original transaction was not processed
by Worldpay), echeckPreNoteCredit, echeckPreNoteSale, echeckSale, echeckVerification,
forceCapture,fraudCheck, sale, updateSubscription

Attributes:
None
Child Elements: (all optional)
name, firstName, middleInitial, lastName, companyName, addressLine1, addressLine2, addressLine3,
city, state, zip, country, email, phone

NOTE: You must submit the name element for echeckSale and echeckCredit transactions. If
you do not submit the customer name in these eCheck transactions, we return the response 709 -
Invalid Data.
For an eCheckVerification transaction, you must submit the firstName and lastName
elements instead of the name element (middleInitial is optional). For a corporate account you
must include the companyName element in addition to the firstName and lastName elements. In
both cases, you also must include the address, city, state, zip and phone information.
For a corporate account, if you do not have the name of the check issuer, you can use a value of
“unavailable” for the firstName and lastName elements.

Example: billToAddress Structure

<billToAddress>
<name>Customer’s Full Name</name>
<firstName>Customer’s First Name</firstName>
<middleInitial>Customer’s Middle Initial</middleInitial>
<lastName>Customer’s Last Name</lastName>
<companyName>Company’s Name</companyName> (include for echeckVerification of
corporate account)
<addressLine1>Address Line 1</addressLine1>
<addressLine2>Address Line 2</addressLine2>
<addressLine3>Address Line 3</addressLine3>
<city>City</city>
<state>State Abbreviation</state>
<zip>Postal Code</zip>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

393
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<country>Country Code</country>
<email>Email Address</email>
<phone>Telephone Number</phone>
</billToAddress>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

394
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.60 bin

The bin element provides the 6-digit Bank (or Issuer) Identification Number of the Issuing Bank. The
system returns this value in XML responses when issuing new tokens to replace Visa or Mastercard
account numbers.
For Discover and American Express cards, this element is empty in a registerTokenResponse.
For Discover, when included with Account Updater information in a payment transaction response, the
bin element will have a value of discov.
Type = String; minLength = 0; maxLength = 6

Parent Elements:
The bin element is an optional child of each listed parent element.
registerTokenResponse, tokenResponse, newCardTokenInfo, originalCardTokenInfo, originalToken,
updatedToken

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

395
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.61 bypassVelocityCheck

The bypassVelocityCheck element is an optional child of the processingInstructions element, which

allows you to specify whether or not the system performs velocity checking on the transaction.

NOTE: Velocity Checking is not currently supported.

Type = Boolean; Valid Values = true or false

Parent Elements:
processingInstructions

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

396
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.62 campaign

The campaign element is an optional child element of the merchantData element. You can use it to
track transactions associated with various marketing campaigns.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
merchantData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

397
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.63 cancelSubscription

The cancelSubscription element is the parent element for the transaction that cancels a
subscription. You can use this element in either Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:
None

Child Elements:
Required: subscriptionId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

398
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.64 cancelSubscriptionResponse

The cancelSubscriptionresponse element is the parent element for the response to a

cancelSubscription transaction.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:
None

Child Elements:
Required: subscriptionId, cnpTxnId, response, message, responseTime
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

399
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.65 capability

The capability element is a required child of the pos element, which describes the capability of the
point of sale terminal.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
pos

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

notused terminal not used

magstripe magnetic stripe reader capability

keyedonly keyed entry only capability

NOTE: For CAT (Cardholder Activated Terminal) transactions, the capability element must be
set to magstripe, the cardholderId element must be set to nopin, and the catLevel element
must be set to self service.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

400
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.66 capture

The capture element is the parent element for all Capture (deposit) transactions. You can use this
element in either Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute
Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored back
in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the consumer.

minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant sub-group in the
user interface where this transaction will be displayed. Please
refer to Coding for Report Groups on page 10 for additional
information.
minLength = 1 maxLength = 25

partial Boolean No If there is more than one capture that references the same
<cnpTxnId>, set this attribute to “true” for each of those partial
captures. The default value is false.
Valid Values = true or false
Note: If you settle in a currency other than US or Canada,
you cannot use partial captures.

Child Elements:
Required: cnpTxnId, payPalOrderComplete (required only if closing a PayPal order)
Optional: amount, enhancedData, payPalNotes, pin, processingInstructions, surchargeAmount,
lodgingInfo

NOTE: If you do not specify an amount, the system uses the full amount from the associated
Authorization transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

401
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.67 captureAmount

The captureAmount element is a required child of the giftCardCapture element and defines the
amount of the capture (deposit). This value must be less than or equal to the value of the
originalAmount element. Setting this element to a value less than the originalAmount implies that
this is a partial capture.
Type = Integer; totalDigits = 12

Parent Elements:
giftCardCapture

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

402
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.68 captureGivenAuth

The captureGivenAuth element is the parent element for all Capture Given Auth transactions. These
are specialized Capture transactions used when the cnpTxnId for the associated Authorization is
unknown or when the Authorization occurred outside our system. You can use this element in either
Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored

back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the consumer.

minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant sub-group in
the user interface where this transaction will be displayed.
Please refer to Coding for Report Groups on page 10 for
additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, authInformation, amount, orderSource, choice of card, token, mpos, or paypage
Optional: billToAddress, shipToAddress, customBilling, taxType, enhancedData, processingInstructions,
pos, merchantData, secondaryAmount, surchargeAmount, debtRepayment, processingType,
originalNetworkTransactionId, originalTransactionAmount, lodgingInfo, merchantCategoryCode

NOTE: If you do not specify an amount child element, the system uses the full amount from the
associated Authorization transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

403
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.69 captureGivenAuthResponse

The captureGivenAuthResponse element is the parent element for information returned to you in
response to a Capture Given Auth transaction. It can be a child of either a cnpOnlineResponse
element or a batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Capture Given Auth transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Capture Given Auth transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Capture Given Auth transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, tokenResponse, giftCardResponse, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

404
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.70 captureResponse

The captureResponse element is the parent element for information returned to you in response to a
Capture transaction. It can be a child of either a cnpOnlineResponse element or a batchResponse
element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, accountUpdater, giftCardResponse, location

NOTE: The system returns the postDate child element in all Online transactions responses.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

405
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.71 card

The card element defines payment card information. It is a required element for most transaction types
unless the transaction uses an alternate payment method such as PayPal. It contains one or more child
elements depending upon whether the transaction is a card-not-present or a card-present (face-to-face)
transaction.

Parent Elements:
activate, activateReversal, accountUpdate, authorization, balanceInquiry, captureGivenAuth, credit,
deactivate, deactivateReversal, depositReversal, forceCapture, giftCardAuthReversal, giftCardCapture,
giftCardCredit, load, loadReversal, refundReversal, sale, unload, unloadReversal, updateSubscription,
fastAccessFunding

Attributes:
None

Child Elements:
For card-not-present transactions (Required): type, number, expDate
For card-present transactions (Required): track
For both transactions types (Optional): cardValidationNum
For Gift Card transactions (Optional): pin

Example: card Structure - Card-Not-Present

<card>
<type>Card Type Abbreviation</type>
<number>Account Number</number>
<expDate>Expiration Date</expDate>
<cardValidationNum>Card Validation Number</cardValidationNum>
</card>

Example: card Structure - Card-Present

<card>
<track>Magnetic Stripe Read</track>
</card>

Example: card Structure - Gift Card (Card-Not-Present)

<card>
<type>GC</type>
<number>Account Number</number>
<expDate>Expiration Date</expDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

406
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<cardValidationNum>Card Validation Number</cardValidationNum>

<pin>Pin Number</pin>
</card>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

407
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.72 cardAcceptorTaxId

The cardAcceptorTaxId element is an optional child of the detailTax element and defines the
merchant's Tax Id. This ID is nine digits long if the merchant is domiciled in the U.S. If the card acceptor
tax ID is unknown, do not include this element.
Type = String; minLength = 1; maxLength = 20

Parent Elements:
detailTax

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

408
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.73 cardholderAuthentication

The cardholderAuthentication element is an optional child element of the Authorization and Sale
transactions. The children of this element have two purposes. The first is to define Verified by Visa or
Mastercard SecureCode data in the Authorization or Sale transactions (authenticationValue,
authenticationTransactionId, and authenticatedByMerchant elements). The remaining child
element, customerIpAddress, as well as the authenticationTransactionId, are used in PayPal
Credit transactions. The customerIpAddress element can also be used to supply the customer IP
Address by merchants enabled for American Express Advanced AVS services.

NOTE: As of September, 2016, the Worldpay eCommerce platform no longer supports PayPal
Credit.

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
authenticationValue, authenticationTransactionId, customerIpAddress, authenticatedByMerchant,
authenticationProtocolVersion

Example: cardholderAuthentication Structure

<cardholderAuthentication>
<authenticationValue>BwABBJQ1AgAAAAAgJDUCAAAAAAA=</authenticationValue>
<authenticationTransactionId>EaOMucALHQqLAEGAgk=</authenticationTransactionId>
<customerIpAddress>Customer Ip</customerIpAddress>
<authenticatedByMerchant>Boolean</authenticatedByMerchant>
<authenticationProtocolVersion>1 or 2</authenticationProtocolVersion>
</cardholderAuthentication>

NOTE: The values for the <authenticationValue> and <authenticationTransactionId>

elements in the example above have been truncated.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

409
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.74 cardholderId

The cardholderId element is a required child of the pos element, which describes the method used for
cardholder identification at the point of sale.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
pos

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

signature customer signature obtained

pin PIN number

nopin unattended terminal - no PIN pad

directmarket mail, telephone, or online

NOTE: For CAT (Cardholder Activated Terminal) transactions, the capability element must be
set to magstripe, the cardholderId element must be set to nopin, and the catLevel element
must be set to self service.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

410
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.75 cardholderName

The cardholderName element is an optional child of the applepayResponse element and provides
the name of the cardholder whose card initiated the Apple Pay transaction.
Type = String; minLength = N/A; maxLength = 512

Parent Elements:
applepayResponse

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

411
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.76 cardOrToken

The cardOrToken element is an abstract that allows the substitution of either the card or token element.
You must specify one of the two substitution elements as a child of the accountUpdate element.

Parent Elements:
accountUpdate

Substitution Options:
card, token

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

412
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.77 cardProductType

The cardProductType element is an optional child of the enhancedAuthResponse element and

whether the card used is commercial or consumer.
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
enhancedAuthResponse

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

COMMERCIAL The card is a commercial card.

CONSUMER The card is a consumer card.

UNKNOWN The type of card is not known.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

413
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.78 cardSuffix

The cardSuffix element is an optional child of both the authorizationResponse and

saleResponse elements. It provides the last four digits of the actual PAN for Apple Pay transactions,
when the underlying card is Visa, Mastercard, or Discover.
Type = String; minLength = 3; maxLength = 6

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

414
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.79 cardValidationNum

The cardValidationNum element is an optional child of the card element, which you use to submit
either the CVV2 (Visa), CVC2 (Mastercard), or CID (American Express and Discover) value.

NOTE: Some American Express cards may have a 4-digit CID on the front of the card and/or a
3-digit CID on the back of the card. You can use either of the numbers for card validation, but not
both.

When you submit the CVV2/CVC2/CID in a registerTokenRequest, the platform encrypts and stores
the value on a temporary basis for later use in a tokenized Auth/Sale transaction submitted without the
value. This is done to accommodate merchant systems/workflows where the security code is available at
the time of token registration, but not at the time of the Auth/Sale. If for some reason you need to change
the value of the security code supplied at the time of the token registration, use an
updateCardValidationNumOnToken transaction. To use the stored value when submitting an
Auth/Sale transaction, set the cardValidationNum value to 000.

NOTE: The use of the cardValidationNum element in the registertokenRequest only

applies when you submit an accountNumber element.

Type = String; minLength = N/A; maxLength = 4

Parent Elements:
card, paypage, token, registerTokenRequest, updateCardValidationNumOnToken

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

415
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.80 cardValidationResult

The cardValidationResult element is an optional child element of the fraudResult element. It

defines the Card Validation response code returned by the networks. For a list of possible values, please
refer to Card Validation Response Codes on page 863.
Type = String; minLength = N/A; maxLength = 2

Parent Elements:
fraudResult

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

416
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.81 cashBackAmount

The cashBackAmount element is an optional child of the giftCardResponse element. It defines the
Cash Back amount provided to the Gift Card holder.

NOTE: Although included in the schema, the beginningBalance, endingBalance, and

cashBackAmount elements are not currently supported.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
giftCardResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

417
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.82 catLevel

The catLevel element is an optional child of the pos element, which describes the capability of the
Cardholder Activated Terminal. Although optional in the schema, it is required for all CAT transactions.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
pos

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

self service Cardholder Activated Terminal level

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

418
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.83 ccdPaymentInformation

The ccdPaymentInformation element is an optional child of the echeck element. This element is
intended for use by PayFacs using Instruction Based Dynamic Payout to submit a description of the
transaction. The description will appear in the extended detail section of the receiver’s bank statement, if
that section is supported by the receiver’s bank.
Type = String; minLength = N/A; maxLength = 80

Parent Elements:
accountInfo, echeck

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

419
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.84 chargeback

The chargeback element is an optional child of the filtering element. To disable the chargeback
filtering operation for a selected transaction include the chargeback element with a setting of false.
Type = Boolean; Valid Value = false

NOTE: Although included in the schema, the <chargeback> element is not supported. To override
the chargeback filter for a selected transaction, use the fraudFilterOverride flag (see
fraudFilterOverride on page 549). Please consult your Relationship Manager for additional
information.

Parent Elements:
filtering

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

420
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.85 checkInDate

The checkInDate element is an optional child of the lodgingInfo element and defines the date the
guest checks into (or plans to check in to) the facility.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

421
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.86 checkNum

The checkNum element is an optional child of the echeck element defining the check number of used in
the transaction.
Type = String; minLength = N/A; maxLength = 15

Parent Elements:
echeck

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

422
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.87 checkOutDate

The checkOutDate element is an optional child of the lodgingInfo element and defines the date the
guest checks out of (or plans to check out of) the facility.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

423
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.88 checkoutId

The checkoutId element is an optional child of the token element specifying the low value token
replacing the CVV value. You use this feature when you already have the consumer’s card (i.e., token) on
file, but wish the consumer to supply the CVV value for a new transaction. This LVT remains valid for 24
hours from the time of issue.

NOTE: For additional information about this element, please refer to the Worldpay Enterprise
eProtect Integration Guide.

Type = String; minLength = 18; maxLength = 18

Parent Elements:
token

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

424
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.89 city

The city element defines the customer’s city name in the billToAddress and shipToAddress
elements. In the customBilling element, city defines the location of the merchant for card-present
transactions.
Type = String; minLength = N/A; maxLength = 35

Parent Elements:
billToAddress, shipFromPostalCode, customBilling

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

425
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.90 clinicOtherAmount

The clinicAmount element is an optional child of the healthcareAmounts element and defines the
healthcare amount used for the clinic/office visits. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
Optional: healthcareAmounts

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

426
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.91 cnpInternalRecurringRequest

The cnpInternalRecurringRequest element and its children is an element structure that exists
solely for internally (to system) generated transactions associated with recurring payments managed by
the Recurring engine. You do not need to code for this structure.

Parent Elements:
sale

Attributes:
None
Child Elements:
subscriptionId, recurringTxnId, finalPayment

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

427
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.92 cnpOnlineRequest

This is the root element for all cnpAPI Online requests.

Parent Elements:
None

Attributes:

Attribute Name Type Required? Description

version String Yes Defines the cnpAPI schema version against which the
XML is validated.
minLength = N/A maxLength = 10

xmlns String Yes Defines the URI of the schema definition. This is a
fixed location and must be specified as:
http://www.vantivcnp.com/schema.
minLength = N/A maxLength = 38

merchantId String Yes A unique string used to identify the merchant within
the system.
minLength = N/A maxLength = 50
Note: International currencies are supported on a
per merchantId basis.

loggedInUser String No Internal Use Only

sameDayFunding Boolean No Used for Dynamic Payout Funding Instructions only.

Set to true to mark this Funding Instructions for same
day funding. Also, see Same Day Funding on page
905.

Child Elements:
Required: authentication
One of the following required: activate, activateReversal, authorization, authReversal, balanceInquiry,
cancelSubscription, capture, captureGivenAuth, createPlan, credit, deactivate, deactivateReversal,
depositReversal, echeckCredit, echeckRedeposit, echeckSale, echeckVerification, echeckVoid,
forceCapture, fraudCheck, giftCardAuthReversal, giftCardCapture, giftCardCredit, load, loadReversal,
registerTokenRequest, refundReversal, sale, unload, updateCardValidationNumOnToken, updatePlan,
updateSubscription, unloadReversal, void, fastAccessFunding, payFacCredit, payFacDebit,
physicalCheckCredit, physicalCheckDebit, reserveCredit, reserveDebit, submerchantCredit,
submerchantDebit, vendorCredit, vendorDebit, customerCredit, customerDebit, payoutOrgCredit,
payoutOrgDebit

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

428
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.93 cnpOnlineResponse

This is the root element for all cnpAPI Online responses.

Parent Elements:
None

Attributes:

Attribute Name Type Required? Description

version String Yes Defines the cnpAPI schema version against which the
XML is validated.
minLength = N/A maxLength = 10

xmlns String Yes Defines the URI of the schema definition. This is a
fixed location and must be specified as:
http://www.vantivcnp.com/schema.
minLength = N/A maxLength = 38

NOTE:NOTE:The system returns responses 2 through 5 and the associated messages only if you use
Open Access/Transact to submit transactions.

response String Yes Indicates whether your XML syntax passed validation.
Expected values are as follows:
0 - XML validation succeeded.
1 - XML validation failed. See the message attribute
for more details.
2 - Indicates that the submitted content was either
improperly formatted XML or non-XML content.
3 - Indicates that the submission contains empty or
invalid credentials (user and password).
4 - Indicates that the merchant has reached the
maximum number of concurrent connections.
5 - Indicates that systems may have detected
message content that violates certain restrictions.
minLength = N/A maxLength = 3

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

429
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Attribute Name Type Required? Description

message String Yes XML validation error message. Expected values are
as follows:
• If the response attribute returns 0, the message
attribute returns the text “Valid Format.”
• If the response attribute returns 1, the message
attribute returns an error message that helps you
to identify and troubleshoot the syntax problem.
See XML Validation Error Messages on page 880
for example messages.
• If the response attribute returns 2, the message
attribute is "System Error - Call Vantiv."
• If the response attribute returns a value of 3, 4, or
5, the message attribute is "There is a problem
with the system. Contact
[email protected]."
minLength = N/A maxLength = 512

Child Elements:
One of the following required: activateResponse, activateReversalResponse, authorizationResponse,
authReversalResponse, balanceInquiryResponse, cancelSubscriptionResponse,
captureGivenAuthResponse, captureResponse, createPlanResponse, deactivateResponse,
deactivateReversalResponse, depositReversalResponse, creditResponse, echeckCreditResponse,
echeckRedepositResponse, echeckSalesResponse, echeckVerificationResponse,
forceCaptureResponse, giftCardAuthReversalResponse, giftCardCaptureResponse,
giftCardCreditResponse, loadResponse, loadReversalResponse, refundReversalResponse,
registerTokenResponse, saleResponse, unloadResponse, unloadReversalResponse,
updateCardValidationNumOnTokenResponse, voidResponse, updatePlanResponse,
updateSubscriptionResponse, fastAccessFundingResponse, payFacCreditResponse,
payFacDebitResponse, physicalCheckCreditResponse, physicalCheckDebitResponse,
reserveCreditResponse, reserveDebitResponse, submerchantCreditResponse,
submerchantDebitResponse, vendorCreditResponse, vendorDebitResponse, customerCreditResponse,
customerDebitResponse, payoutOrgCerditResponse, payoutOrgDebitResponse

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

430
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.94 cnpRequest

This is the root element for all cnpAPI Batch requests.

Parent Elements:
None

Attributes:

Attribute Name Type Required? Description

version String Yes Defines the cnpAPI schema version against which the
XML is validated.
minLength = N/A maxLength = 10

xmlns String Yes Defines the URI of the schema definition. This is a
fixed location and must be specified as:
http://www.vantivcnp.com/schema.
minLength = N/A maxLength = 38

id String No A unique string to identify the session within the

system.
minLength = N/A maxLength = 25

numBatchRequests Integer Yes Defines the total number of batchRequest children

included in the cnpRequest. If the cnpRequest
contains only an RFRRequest, then set this attribute
to “0”.

Child Elements:
Required: authentication
One of the following required: batchRequest, RFRRequest

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

431
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.95 cnpResponse

This is the root element for all cnpAPI Batch responses.

Parent Elements:
None

Attributes:

Attribute Name Type Required? Description

version String Yes Defines the cnpAPI schema version against which the XML is
validated.
minLength = N/A maxLength = 10

xmlns String Yes Defines the URI of the schema definition. This is a fixed location
and must be specified as: http://www.vantivcnp.com/schema.
minLength = N/A maxLength = 38

id String No The response returns the same value submitted in the cnp
Request.
minLength = N/A maxLength = 25

response String Yes Indicates whether your XML syntax passed validation. Expected
values are as follows:
0 - XML validation succeeded.
1 - XML validation failed. See the message attribute for more
details.
minLength = N/A maxLength = 3

message String Yes XML validation error message. Expected values are as follows:
• If the response attribute returns 0, the message attribute
returns the text “Valid Format.”
• If the response attribute returns 1, the message attribute
returns an error message that helps you to identify and
troubleshoot the syntax problem. See XML Validation Error
Messages on page 880 for example messages.
minLength = N/A maxLength = 512

cnpSessionId Long Yes A unique value assigned by Worldpay to identify the session.
minLength = N/A maxLength = 19

Child Elements:
One of the following required: batchResponse, RFRResponse

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

432
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.96 cnpSessionId

The cnpSessionId element is a child of the RFRRequest element used to request the response from a
previously submitted Batch. The value of the cnpSessionId must be the same at the value returned in
the corresponding attribute of the cnpResponse.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
RFRRequest

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

433
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.97 cnpToken

The cnpToken element defines the value of the token. The system returns this value in XML responses
when issuing new tokens to replace account numbers. The length of the token is the same as the length
of the submitted account number for credit card tokens or a fixed length of seventeen (17) characters for
Direct Debit account tokens.
Type = String; minLength = 13; maxLength = 25

Parent Elements:
The cnpToken element is an optional child of each listed parent element.
registerTokenResponse, tokenResponse, newCardTokenInfo, originalCardTokenInfo, originalToken,
originalTokenInfo, newTokenInfo, updatedToken, token, echeckToken

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

434
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.98 cnpTxnId

The cnpTxnId element is used to identify transactions in the system. The system returns this element in
XML responses. You use it in various requests to reference the original transaction. For example, when
you submit a Capture transaction, you include the cnpTxnId for the associated Authorization.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
This element is a required child of the following: accountUpdateResponse, activateResponse,
activateReversalResponse, authorizationResponse, authReversalResponse, capture, captureResponse,
credit, creditResponse, captureGivenAuthResponse, customerCreditResponse, customerDebitResponse,
deactivateResponse, deactivateReversalResponse, depositReversalResponse, echeckCredit,
echeckCreditResponse, echeckPreNoteCreditResponse, echeckPreNoteSaleResponse,
echeckRedeposit, echeckRedepositResponse, echeckSalesResponse, echeckVerificationResponse,
echeckVoid, echeckVoidResponse, fastAccessFundingResponse, forceCapture, forceCaptureResponse,
fraudCheckResponse, fundingInstructionVoid, fundingInstructionVoidResponse,
giftCardAuthReversalResponse, giftCardCaptureResponse, giftCardCreditResponse, loadResponse,
loadReversalResponse, payFacCreditResponse, payFacDebitResponse, physicalCheckCreditResponse,
physicalCheckDebitResponse, refundReversalResponse, saleResponse, unloadResponse, void,
voidResponse, cancelSubscriptionResponse, updatePlanResponse, updateSubscriptionResponse,
unloadReversalResponse, submerchantCreditResponse, submerchantDebitResponse,
vendorCreditResponse, vendorDebitResponse

NOTE: While the cnpTxnId is optional in the transaction types listed below, Worldpay
recommends you include it whenever possible. Failure to include the cnpTxnId results in missing
information in the Associated Transaction Stream section of the Transaction Detail screen in iQ.

This element is an optional child of the following: activateReversal, deactivateReversal, depositReversal,

giftCardAuthReversal, giftCardCapture, giftCardCredit, loadReversal, refundReversal, unloadReversal

NOTE: Although the schema shows the cnpTxnId element as an optional child of the
authorization, echeckSale, and sale transactions, under normal circumstances, merchants
would never use this option.

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

435
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.99 code

The code element is a required child of the extendedCardResponse element. The code/message
combination can be either 501- The account was closed, or 504 - Contact the cardholder for updated
information.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
extendedCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

436
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.100 commodityCode

The commodityCode element is an optional child of the lineItemData element, which specifies the
Identifier assigned by the card acceptor that categorizes the purchased item. Although the schema
defines it as an optional child of the enhancedData element, it is required by Visa for Level III
interchange rates.
Type = String; minLength = 1; maxLength = 12

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

NOTE: A commodity code is a numeric code representing a particular product or service. The code
can be 3, 5, 7, or 11 digits in length. The longer the code the more granular the description of the
product/service. For example, code 045 is used for Appliances and Equipment, Household Type,
while code 04506 represents the sub-set of Appliances, Small Electric.
The codes are issued by the NIGP (National Institute of Governmental Purchasing. Their site,
www.nigp.com, offers a subscription based code search engine, as well as downloadable lists for
purchase.
You can also find many lists published online by performing a simple search on “Commodity Codes”.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

437
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.101 companyName

The companyName element is an optional child of the billToAddress element, which specifies the
name of the company associated with the corporate checking account. This element is required when
performing an eCheck Verification of a check from a corporate account, as defined by the <accType>
child of the <echeck> element.
Type = String; minLength = N/A; maxLength = 40

Parent Elements:
billToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

438
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.102 country

The country element defines the country portion of the postal mailing address in both the
billToAddress and shipToAddress elements.
Type = String (Enum); minLength = N/A; maxLength = 3

NOTE: The enumerations for this element are listed under <countryTypeEnum> in the cnpAPI
Common XSD. The country names corresponding to the abbreviations can be found in the ISO
3166-1 standard.
All Country Codes are 2-character except for the United States, which accepts both US and USA.

Parent Elements:
billToAddress, shipFromPostalCode

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

439
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.103 createAddOn

The createAddOn element is the parent of several child elements used to define an additional charge
added to a new or existing subscription.

Parent Elements:
subscription, updateSubscription

Attributes:
None
Child Elements (all Required):
addOnCode, name, amount, startDate, endDate

Example: customerInfo Structure

<createAddOn>
<addOnCode>Add On Reference Code</addOnCode>
<name>Name of Add On</name>
<amount>Amount of Add On</amount>
<startDate>Start Date of Add On Charge</startDate>
<endDate>End Date of Add On Charge</endDate>
</createAddOn>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

440
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.104 createDiscount

The createDiscount element is the parent of several child elements used to define a discount to be
applied to a new or existing subscription.

Parent Elements:
subscription, updateSubscription

Attributes:
None
Child Elements (all Required):
discountCode, name, amount, startDate, endDate

Example: customerInfo Structure

<createDiscount>
<discountCode>Discount Reference Code</discountCode>
<name>Name of Discount</name>
<amount>Amount of Discount</amount>
<startDate>Start Date of Discount</startDate>
<endDate>End Date of Discount</endDate>
</createDiscount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

441
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.105 createPlan

The createPlan element is the parent of several child element that define the attributes of a recurring
payment plan. You associate Plans with subscriptions to define the billing behavior for the recurring
payment.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:
None

Child Elements:
planCode, name, description, intervalType, amount, numberOfPayments, trialNumberOfIntervals,
trialIntervalType, active

Example: createPlan Structure

<createPlan>
<planCode>Plan Reference Code</planCode>
<name>Name of Plan</name>
<description>Description of Plan</description>
<intervalType>The Type of Interval</intervalType>
<amount>Amount of Recurring Payment</amount>
<numberOfPayments>1 to 99</numberOfRemianingPayments>
<trialNumberOfIntervals>Number of Trial Period Intervals</trialNumberOfIntervals>
<trialIntervalType>Type of Trial Period Interval</trialIntervalType>
<active>true or false</active>
</createPlan>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

442
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.106 createPlanResponse

The createPlanResponse element is the parent element for the response to a createPlan
transaction.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:
None

Child Elements:
planCode, cnpTxnId, response, message, responseTime, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

443
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.107 credit

The credit element is the parent element for all Credit transactions. You can use this element in either
Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored

back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the consumer.

minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant sub-group in
the user interface where this transaction will be displayed.
Please refer to Coding for Report Groups on page 10 for
additional information.
minLength = 1 maxLength = 25

Child Elements:
For credits to transactions processed by Worldpay (Required): cnpTxnId
For credits to transactions processed by Worldpay (Optional): amount, payPalNotes, pin,
secondaryAmount, surchargeAmount

NOTE: If you do not specify an amount, the system uses the full amount from the associated
settlement transaction.
You must include the amount element for credits to transactions not processed by Worldpay.

For credits to transactions not processed by Worldpay (Required): orderId, amount, orderSource, choice
of card, token, paypage, mpos, paypal, or applepay
For credits to transactions not processed by Worldpay (Optional): billToAddress, merchantCategoryCode
For both transaction types (Optional): customBilling, taxType, enhancedData, processingInstructions,
merchantData, actionReason, pos, lodgingInfo

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

444
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.108 creditAmount

The creditAmount element is a required child of the giftCardCredit transaction, where it specifies the
amount of the refund. Supply the value in cents without a decimal point. For example, a value of 1995
signifies $19.95.
Type = Integer; totalDigits = 12

Parent Elements:
giftCardCredit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

445
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.109 creditCnpTxnId

The creditCnpTxnId element is the Transaction Id (cnpTxnId) of a Credit transaction automatically

submitted under the following conditions:
• You submitted a Void transaction to halt the recycling of a declined Sale transaction by the
Recovery/Recycling Engine.
• The Sale transaction has already been approved and captured.
• Your Recovery/Recycling Engine configuration enables automatic refunds.
• The system has successfully submitted a Credit transaction on your behalf.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
recyclingResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

446
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.110 creditResponse

The creditResponse element is the parent element for information returned to you in response to a
Credit transaction. It can be a child of either a cnpOnlineResponse element or a batchResponse
element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
credit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
credit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
credit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, tokenResponse, giftCardResponse, applepayResponse, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

447
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.111 cryptogram

The cryptogram element is an optional child of the androidResponse element and provides the
BASE64 Encoded signature cryptogram associated with the Google Pay transaction.
Type = Base 64 Encoded String; minLength = N/A; maxLength = 56

Parent Elements:
androidpayResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

448
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.112 currencyCode

The currencyCode element is an optional child of the applepayResponse element and provides the
3-character code for the currency used in the transaction.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
applepayResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

449
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.113 customAttribute1

The customAttribute1 through customAttribute5 elements are an optional children of the

advancedFraudChecks element. These elements allow users of Advanced Fraud Tools with self-serve
rules to submit additional custom data for inclusion in the fraud evaluation process. For example, if you
assigned a certain attribute to your customers for segmentation purposes, you might wish to submit the
assigned value and also establish a fraud rule to include the value in the evaluation.

NOTE: Once you decide to use a particular custom attribute for a value set and establish a rule for
its evaluation, you can not change it at a later date.

Type = String; minLength = 1; maxLength = 200

Parent Elements:
advancedFraudChecks

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

450
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.114 customBilling

The customBilling element allows you to specify custom billing descriptor information for the
transaction. This billing descriptor is used instead of the descriptor defined as the default billing
descriptor. If you do not define this element, the system uses the default.

NOTE: If you submit a captureGivenAuth transaction with a customBilling element and

Worldpay finds a matching Authorization (see Capture Given Auth Transaction on page 73), the
system uses the customBilling information from the Authorization and discards the information from
the captureGivenAuth.

Parent Elements:
authorization, captureGivenAuth, credit, echeckCredit, echeckSale, forceCapture, sale

NOTE: Although the schema includes the customBilling element as a child of echeckCredit and
echeckSale, Worldpay does not support its use in these instances.

Attributes:
None
Child Elements:
Required for card-not-present transactions: phone, or url

NOTE: Please consult your Relationship Manager prior to using the <url> element. The contents of
this element are discarded unless Worldpay specifically enables to use it in your cnpAPI
submissions.

Required for card present transactions: city

Optional for either: descriptor

Example: customBilling Structure - Card-Not-Present (using phone child)

<customBilling>
<phone>Telephone Number</phone>
<descriptor>Billing Descriptor</descriptor>
</customBilling>

Example: customBilling Structure - Card-Not-Present (using url child)

<customBilling>
<url>retail.url</url>
<descriptor>www.retail.com</descriptor>
</customBilling>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

451
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: customBilling Structure - Card-Present

<customBilling>
<city>City</city>
<descriptor>Billing Descriptor</descriptor>
</customBilling>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

452
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.115 customIdentifier

The customIdentifier element is an optional child of Sub-merchant funding instruction request

transaction types, as well as eCheck Sale/Credit/Redeposit requests. Payment Facilitators/Merchants can
use this element to specify a Billing Descriptor to appear on the bank statements of the parties involved in
the funds transfer or Direct Debit transaction.

NOTE: The information you provide in this element populates the Individual ID field of the ACH
Record. The use of this field and its appearance on bank statements is at the discretion of the bank
producing the statement.

Type = String; minLength = N/A; maxLength = 15

Parent Elements:
echeckCredit, echeckRedeposit, echeckSale, submerchantCredit, submerchantDebit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

453
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.116 customerCredit

The customerCredit element is the parent element for the transaction type that a merchant enabled for
Dynamic Payout uses to move funds from their Settlement Account to a customer Account.

NOTE: You can only use this transaction type if enabled for Dynamic Payout and one of the
following MCCs: 4829 (VI and MC), 7800 (VI and MC), 7801 (VI only), and 7802 (VI only).

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundingCustomerId, fundsTransferId, customerName, customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

454
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.117 customerCreditResponse

The customerCreditResponse element is the parent element for information returned to you in
response to a customerCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
customerCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
customerCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
customerCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

455
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.118 customerDebit

The customerDebit element is the parent element for the transaction type that a merchant enabled for
Dymanic Payout uses to move funds from the customer account to their own Settlement Account.

NOTE: You can only use this transaction type if enabled for Dynamic Payout and one of the
following MCCs: 4829 (VI and MC), 7800 (VI and MC), 7801 (VI only), and 7802 (VI only).

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundingCustomerId, fundsTransferId, customerName, customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

456
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.119 customerDebitResponse

The customerDebitResponse element is the parent element for information returned to you in
response to a customerDebit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
customerDebit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
customerDebit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
customerDebit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

457
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.120 customerInfo

The customerInfo element is the parent of several child elements use to define customer information.

Parent Elements:
authorization, sale

Attributes:
None
Child Elements:
ssn, dob, customerRegistrationDate, customerType, incomeAmount, incomeCurrency, employerName,
customerWorkTelephone, residenceStatus, yearsAtResidence, yearsAtEmployer

Example: customerInfo Structure

<customerInfo>
<ssn>ssn</ssn>
<dob>dob</dob>
<customerRegistrationDate>customerRegistrationDate</customerRegistrationDate>
<customerType>customerType</customerType>
<incomeAmount>incomeAmount</incomeAmount>
<incomeCurrency>incomeCurrency</incomeCurrency>
<employerName>employerName</employerName>
<customerWorkTelephone>customerWorkTelephone</customerWorkTelephone>
<residenceStatus>residenceStatus</residenceStatus>
<yearsAtResidence>yearsAtResidence</yearsAtResidence>
<yearsAtEmployer>yearsAtEmployer</yearsAtEmployer>
</customerInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

458
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.121 customerIpAddress

The customerIpAddress element is an optional child element of the cardholderAuthentication

element. This element defines the IP Address of the customer's system. This element is used to supply
the customer IP Address by merchants enabled for American Express Advanced AVS services.
Type = Ip Address; Format = nnn.nnn.nnn.nnn

Parent Elements:
cardholderAuthentication

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

459
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.122 customerName

The customerName element is a required child of the customerCredit and customerDebit

elements, where it specifies the name of the customer impacted by the funding instruction.
Type = String; minLength = 1; maxLength = 256

Parent Elements:
customerCredit, customerDebit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

460
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.123 customerReference

The customerReference element defines a reference string used by the customer for the purchase (for
example, a Purchase Order Number). Although the schema defines it as an optional child of the
enhancedData element, Worldpay recommends you include the element if a value is available/supplied
and omit this element if it is blank.
Type = String; minLength = 1; maxLength = 17

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

461
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.124 customerRegistrationDate

The customerRegistrationDate element is an optional child of the customerInfo element defining

the earliest date on file with this customer. The latest allowable date is the current date. It is used in
combination with several other elements to provide required information for some PayPal Credit
transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Date; Format = YYYY-MM-DD

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

462
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.125 customerServicePhone

The customerServicePhone element is an optional child of the lodgingInfo element and defines
customer service number of the facility.
Type = String; minLength = N/A; maxLength = 17

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

463
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.126 customerType

The customerType element is an optional child of the customerInfo element defining whether the
customer is a new or existing customer. An existing customer is a customer in good standing that has
been registered with the merchant for a minimum of 30 days and has made at least one purchase in the
last 30 days. It is used in combination with several other elements to provide required information for
some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Choice (Enum); Enumerations = New or Existing

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

464
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.127 customerWorkTelephone

The customerWorkTelephone element is an optional child of the customerInfo element and defines
the customer’s work telephone number. It is used in combination with several other elements to provide
information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

465
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.128 ctxPaymentDetail

The ctxPaymentDetail element is an optional child of the ctxPaymentInformation element.

Payment Facilitators can use this element to submit a description of certain Instruction Based Dynamic
Payout transactions. The description appears on the receiver’s bank statement, if supported by the
receiver’s bank. You can include up to 9,999 ctxPaymentDetail elements in the transaction.
Type = String; minLength = N/A; maxLength = 80

Parent Elements:
ctxPaymentInformation

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

466
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.129 ctxPaymentInformation

The ctxPaymentInformation element is an optional child of the accountInfo element for Batch
submitted transactions only. Payment Facilitators can use this element to submit a description of certain
Instruction Based Dynamic Payout transactions. You define the description using the
ctxPaymentDetail child element. The information appears in the extended detail section of the
receiver’s bank statement, if supported by the receiving bank.

Parent Elements:
accountInfo

Attributes:
None
Child Elements:
ctxPaymentDetail

Example: cxtPaymentInformation Structure

<ctxPaymentInformation>
<ctxPaymentDetail>Payment Description 1</ctxPaymentDetail>
<ctxPaymentDetail>Payment Description 2</ctxPaymentDetail>
.
.
.
<ctxPaymentDetail>Payment Description n</ctxPaymentDetail>
</ctxPaymentInformation>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

467
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.130 data

The data element is a required child of the applepay element. It is the payment data dictionary,
BASE64 encoded string from the PKPaymentToken.
Type = String; minLength = N/A; maxLength = 2000

Parent Elements:
applepay

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

468
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.131 deactivate

The deactivate element is the parent element for the transaction type that deactivate a Gift Card.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (all Required)

orderId, orderSource, card

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

469
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.132 deactivateResponse

The deactivateResponse element is the parent element for information returned to you in response to
a deactivate transaction. It can be a child of either a cnpOnlineResponse element or a
batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Deactivate transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Deactivate transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Deactivate transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, fraudResult, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

470
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.133 deactivateReversal

The deactivateReversal element is the parent element for the transaction type that reverses the
deactivation of a Gift Card.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

471
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.134 deactivateReversalResponse

The deactivateReversalResponse element is the parent element for information returned to you in
response to an deactivateReversal transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Deactivate Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Deactivate Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Deactivate Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

472
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.135 debitNetworkName

The debitNetworkName element is a required child of the preferredDebitNetworks element and

defines the name of the preferred debit network. You can use this element up to 12 times in a transaction
to designate a list of preferred debit networks in priority order. The use of this element applies only to
merchants using the Prime - PINless Debit Routing service.
Valid values for this element are: Accel, Jeanie, NYCE, Pulse, STAR SouthEast, STAR West, and STAR
NorthEast.

NOTE: Worldpay supports the above Debit Networks for the following orderSource values:
recurring and installment.
Each Debit Network requires registration. Please consult your Implementation Consultant.

Type = String; minLength = N/A; maxLength = 25

Parent Elements:
preferredDebitNetworks

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

473
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.136 debtRepayment

The debtRepayment element is an optional child of authorization, captureGivenAuth, forceCapture, and

sale transactions. You use this flag only if the method of payment is Visa and the transaction is a for a
debt repayment. Also, your MCC must be either 6012 or 6051. If you set this flag to true and you are not
one of the allowed MCCs, the system declines the transaction with a Response Reason Code of 852 -
Debt Repayment only allowed for VI transactions on MCCs 6012 and 6051.
Type = Boolean; Valid Values = true or false (default)

Parent Elements:
authorization, captureGivenAuth, forceCapture, sale

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

474
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.137 deleteAddOn

The deleteAddOn element is the parent element used to define an Add On to be removed from an
existing subscription.

Parent Elements:
updateSubscription

Attributes:
None
Child Elements (all Required):
addOnCode

Example: deleteAddOn Structure

<deleteAddOn>
<addOnCode>Add On Reference Code</addOnCode>
</deleteAddOn>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

475
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.138 deleteDiscount

The deleteDiscount element is the parent element used to define a discount to be removed from an
existing subscription.

Parent Elements:
updateSubscription

Attributes:
None
Child Elements (all Required):
discountCode

Example: deleteDiscount Structure

<deleteDiscount>
<discountCode>Discount Reference Code</discountCode>
</deleteDiscount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

476
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.139 deliveryType

The deliveryType element is an optional child of the enhancedData element and defines the shipping
method used for delivery of the product.
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
enhancedData

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

CNC Cash and Carry

DIG Digital Delivery

PHY Physical Delivery

SVC Service Delivery

TBD (default) To be determined.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

477
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.140 dentalAmount

The dentalAmount element is an optional child of the healthcareAmounts element and defines the
healthcare amount used for dental related purchases. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
Optional: healthcareAmounts

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

478
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.141 depositReversal

The depositReversal element is the parent element for a Gift Card specific transaction type that
reverses a giftCardCapture or sale transaction.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

479
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.142 depositReversalResponse

The depositReversalResponse element is the parent element for information returned to you in
response to an depositReversal transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Deposit Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Deposit Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Deposit Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

480
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.143 description

The description element is an optional child of the createPlan element and provides a text
description of the Plan.
Type = String; minLength = N/A; maxLength = 100

Parent Elements:
createPlan

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

481
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.144 descriptor

The descriptor element is an optional child of the customBilling element. This element defines the
text you wish to display on the customer bill, enabling the customer to better recognize the charge.
Type = String; minLength = 4; maxLength = 25

NOTE: If you include a prefix:

• the prefix must be either 3, 7, or 12 characters in length.
• you must use an asterisk (*) after the prefix as a separator, in one of the
following positions: 4th, 8th, or 13th. Do not use an asterisk in more than one
position.
• Use only the following valid characters:
– Numbers
– Letters
– Special characters as follows: ampersand, asterisk (Required; see note
above), comma, dash, period, space, or pound sign.

Parent Elements:
customBilling

Attributes:
None
Child Elements:
None

NOTE: When using a descriptor with eChecks, Worldpay maps the first 16 characters to the
Company Name field of the ACH message and the last nine characters as the company phone
number.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

482
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.145 destinationCountryCode

The destinationCountryCode element defines the country portion of the postal mailing address in
the enhancedData element.
Type = String (Enum); minLength = N/A; maxLength = 3

NOTE: The enumerations for this element are listed under <countryTypeEnum> in the cnpAPI
Common XSD. The country names corresponding to the abbreviations can be found in the ISO
3166-1 standard.

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

483
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.146 destinationPostalCode

The destinationPostalCode element defines the postal code of the destination in the
enhancedData element.
Type = String; minLength = N/A; maxLength = 20

NOTE: Although the schema specifies the maxLength of the <destinationPostalCode>

element as 20 characters, in practice you should never exceed 10 characters in your submissions.

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

484
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.147 detailTax

The detailTax element is an optional child of both the enhancedData and lineItemData elements,
which you use to specify detailed tax information (for example, city or local tax). The total sum of the
detailTax values should match either the salesTax value, if detailTax is a child of enhancedData,
or the taxAmount element if detailTax is a child of lineItemData.

Parent Elements:
enhancedData, lineItemData

NOTE: The detailTax element can appear a maximum of six times as a child of either parent.

Attributes:
None

Child Elements:
Required: taxAmount
Optional: taxIncludedInTotal, taxRate, taxTypeIdentifier, cardAcceptorTaxId

Example: detailTax Structure

<detailTax>
<taxIncludedInTotal>true or false</taxIncludedInTotal>
<taxAmount>Additional Tax Amount</taxAmount>
<taxRate>Tax Rate of This Tax Amount</taxRate>
<taxTypeIdentifier>Tax Type Enum</taxTypeIdentifier>
<cardAcceptorTaxId>Tax ID of Card Acceptor</cardAcceptorTaxId>
</detailTax>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

485
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.148 deviceManufacturerIdentifier

The deviceManufacturerIdentifier element is an optional child of the applepayResponse

element and defines the manufacturer of the device originating the transaction.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
applepayResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

486
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.149 deviceReputationScore

The deviceReputationScore element is an optional child of the advancedFraudResults element

and specifies score resulting from the ThreatMetrix analysis of the customer device.
Type = Integer; totalDigits = 8

Parent Elements:
advancedFraudResults

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

487
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.150 deviceReviewStatus

The deviceReviewStatus element is an optional child of the advancedFraudResults element and

specifies the results of the comparison of the deviceReputationScore against the threshold levels
configured for the merchant. Typical values are: pass, fail, review, unavailable, and invalid_session.

NOTE: The system returns invalid_session if you submitted a session Id using an invalid prefix.

Type = String; minLength = N/A; maxLength =

Parent Elements:
advancedFraudResults

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

488
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.151 disbursementType

The disbursementType element is an optional child of the fastAccessFunding element, which

describes the funds disbursement associated with the transaction. If you do not include this element, the
value defaults to VMD, Merchant Disbursement.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
fastAccessFunding

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

VAA Account to Account

ABB Business to Business

VBI Money Transfer - Bank-initiated

VBP Non-card Bill Payment

VCC Cash Claim

VCI Cash In

VCO Cash Out

VCP Card Bill Payment

VFD Funds Disbursement

VGD Government Disbursement

VGP Gambling Payout

VLO Loyalty and Offers

VMA Mobile Air Time Payout

VMD Merchant Disbursement (default)

VMI Money Transfer - Merchant-initiated

VMP Face-to-face Merchant Payment

VOG Online Gambling Payout

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

489
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Enumeration Description

VPD Payroll/Pension Disbursement

VPG Payment to Government

VPP Person to Person

VPS Payment for Goods and Services

VTU Top-up for Enhanced Prepaid Loads

VWT Wallet Transfer

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

490
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.152 discountAmount

The discountAmount element defines the amount of the discount for the order. Although the schema
defines it as an optional child of the enhancedData element, it is required by Visa for Level III
interchange rates. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

491
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.153 discountCode

The discountCode element is the identifier of a defined discount. You use this element when creating,
updating, and deleting a discount applied to a subscription.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
createDiscount, updateDiscount, deleteDiscount

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

492
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.154 dob

The dob element is an optional child of the customerInfo element. It is used in combination with
several other elements to provide required information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Date; Format = YYYY-MM-DD

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

493
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.155 duration

The duration element is an optional child of the lodgingInfo element and defines the number of
nights the guest stays (or plans to stay) at the facility (see Note below).

NOTE: For a Discover transaction, <duration> is: number of nights * number of rooms. Also, for
Visa transactions, the totalDigits = 2 not 4.

Type = Integer; totalDigits = 4 (2 for Visa transactions)

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

494
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.156 dutyAmount

The dutyAmount element defines duty on the total purchased amount for the order. Although the
schema defines it as an optional child of the enhancedData element, it is required by Visa for Level III
interchange rates. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

495
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.157 echeck

The echeck element is a required child of the echeckSale, echeckVerification, and

echeckCredit (when the credit is against a transaction not originally processed through our system)
elements. It contains child elements used to provide details concerning the Direct Debit account.

Parent Elements:
echeckCredit, echeckPreNoteCredit, echeckPreNoteSale, echeckSale, echeckVerification

Attributes:
None

Child Elements:
Required: accType, accNum, routingNum
Optional: checkNum, ccdPaymentInformation

Example: echeck Structure

<echeck>
<accType>Account Type Abbreviation</accType>
<accNum>Account Number</accNum>
<routingNum>Routing Number</routingNum>
<checkNum>Check Number</checkNum>
<ccdPaymentInformation>Payment Description</ccdPaymentInformation>
</echeck>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

496
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.158 eCheckAccountSuffix

The eCheckAccountSuffix element is an optional child of the tokenResponse element that provides
the last three characters of the Direct Debit account number.
Type = String; minLength = 3; maxLength = 3

Parent Elements:
registerTokenResponse, tokenResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

497
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.159 echeckCredit

The echeckCredit element is the parent element for all eCheck Credit transactions. You can use this
element in either Batch or Online transactions.

IMPORTANT: Although the schema includes the customBilling element as a child of echeckCredit
and echeckSale, Worldpay does not support its use in these instances.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute
Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored back in the
response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the consumer.

minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant sub-group in the user
interface where this transaction will be displayed. Please refer to
Coding for Report Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
For credits to transactions processed by Worldpay (Required): cnpTxnId
For credits to transactions processed by Worldpay (Optional): amount

NOTE: Omit the amount child element, to use the full from the echeckSale.

For credits to transactions not processed by Worldpay (Required): orderId, amount, orderSource,
billToAddress, (choice of) echeck or echeckToken
For credits to transactions not processed by Worldpay (Optional): merchantData
For both (Optional): customBilling, secondaryAmount, customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

498
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.160 echeckCreditResponse

The echeckCreditResponse element is the parent element for information returned to you in response
to an echeckCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
echeckCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 25

Child Elements: (all Required)

cnpTxnId, response, responseTime, message
Optional: postDate, accountUpdater, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

499
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.161 echeckForToken

The echeckForToken element is a child of the registerTokenRequest element. It contains the

routing and account number of the Direct Debit account which the system uses to generate a token.

Parent Elements:
registerTokenRequest

Attributes:
None

Child Elements:
Required: accNum, routingNum

Example: echeck Structure

<echeckForToken>
<accNum>Account Number</accNum>
<routingNum>Routing Number</routingNum>
</echeckForToken>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

500
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.162 echeckPreNoteCredit

The echeckPreNoteCredit element is the parent element for all eCheck Prenotification Credit
transactions. You use this transaction type to perform an eCheck Prenotification, when the subsequent
Direct Debit transaction will be an eCheck Credit transaction. You can use this element only in Batch
transactions. This transaction type is only supported for US transactions.

Parent Elements:
batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, orderSource, billToAddress, echeck
Optional: merchantData

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

501
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.163 echeckPreNoteCreditResponse

The echeckPreNoteCreditResponse element is the parent element for information returned to you in
response to an echeckPreNoteCredit transaction.

Parent Elements:
batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
echeckCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 25

Child Elements: (all Required)

cnpTxnId, response, responseTime, message

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

502
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.164 echeckPreNoteSale

The echeckPreNoteSale element is the parent element for all eCheck Prenotification Sale transactions.
You use this transaction type to perform an eCheck Prenotification, when the subsequent eCheck
transaction will be an eCheck Sale transaction. You can use this element only in Batch transactions. This
transaction type is only supported for US transactions.

Parent Elements:
batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, orderSource, billToAddress, echeck
Optional: merchantData

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

503
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.165 echeckPreNoteSaleResponse

The echeckPreNoteSaleResponse element is the parent element for information returned to you in
response to an echeckPreNoteSale transaction.

Parent Elements:
batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
echeckCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
echeckCredit transaction.
minLength = 1 maxLength = 25

Child Elements: (all Required)

cnpTxnId, response, responseTime, message

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

504
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.166 echeckRedeposit

The echeckRedeposit element is the parent element for all eCheck Redeposit transactions. You use
this transaction type to manually attempt redeposits of eChecks returned for either Insufficient Funds or
Uncollected Funds. You can use this element in either Batch or Online transactions.

NOTE: Do not use this transaction type if you are enabled for the Auto Redeposit feature. If you are
enabled for the Auto Redeposit feature, the system will reject any echeckRedeposit transaction
you submit.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId
Optional: (choice of) echeck or echeckToken, merchantData, customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

505
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.167 echeckRedepositResponse

The echeckRedepositResponse element is the parent element for information returned to you in
response to an echeckRedeposit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
echeckSale transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
echeckSale transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
echeckSale transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, accountUpdater, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

506
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.168 echeckSale

The echeckSale element is the parent element for all eCheck Sale transactions. You can use this element
in either Batch or Online transactions.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, amount, orderSource, billToAddress, (choice of) echeck or echeckToken

NOTE: The value for the orderSource element must be one of the following: telephone,
ecommerce, recurringtel, or echeckppd.

Optional: shipToAddress, verify, customBilling, merchantData, secondaryAmount, customIdentifier

NOTE: Although the schema includes the customBilling element as a child of echeckCredit and
echeckSale, Worldpay does not support its use in these instances.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

507
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.169 echeckSalesResponse

The echeckSalesResponse element is the parent element for information returned to you in response
to an echeckSale transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
echeckSale transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
echeckSale transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
echeckSale transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, accountUpdater, tokenResponse, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

508
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.170 echeckToken

The echeckToken element replaces the echeck element in tokenized Direct Debit transactions and
defines the tokenized account information.

Parent Elements:
echeckCredit, echeckRedeposit, echeckSale, echeckVerification

Attributes:
None

Child Elements:
Required: cnpToken, routingNum, accType
Optional: checkNum

Example: echeck Structure

<echeckToken>
<cnpToken>Token</cnpToken>
<routingNum>Routing Number</routingNum>
<accType>Account Type Abbreviation</accType>
<checkNum>Check Number</checkNum>
</echeckToken>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

509
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.171 echeckVerification

The echeckVerification element is the parent element for all eCheck Verification transactions. You
use this transaction type to initiate a comparison of the consumer’s account information against
positive/negative databases. You can use this element in either Batch or Online transactions. This
transaction type is only supported for US transactions.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, amount, orderSource, billToAddress, (choice of) echeck or echeckToken
Optional: merchantData

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

510
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.172 echeckVerificationResponse

The echeckVerificationResponse element is the parent element for information returned to you in
response to a eCheck Verification transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

511
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.173 echeckVoid

The echeckVoid element is the parent element for all eCheck Void transactions. You use this transaction
type to either cancel an eCheck Sale transaction, as long as the transaction has not yet settled, or halt
automatic redeposit attempts of eChecks returned for either Insufficient Funds or Uncollected Funds. You
can use this element only in Online transactions.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

512
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.174 echeckVoidResponse

The echeckVoidResponse element is the parent element for information returned to you in response to
an eCheck Void transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
void transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
void transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
void transaction.
minLength = 1 maxLength = 25

Child Elements: (all Required)

Required: cnpTxnId, response, responseTime, message, postDate
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

513
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.175 eciIndicator

The eciIndicator element is an optional child of the applepayResponse and

androidpayResponse elements and specifies electronic commerce indicator associated with an Apple
Pay/Google Pay transaction.
Type = String; minLength = N/A; maxLength = 2

Parent Elements:
applepayResponse, androidpayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

514
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.176 email

The email element defines the email address of the customer in both the billToAddress and
shipToAddress elements.
Type = String; minLength = N/A; maxLength = 100

Parent Elements:
billToAddress, shipToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

515
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.177 employerName

The employerName element is an optional child of the customerInfo element and defines the name of
the customer’s place of employment. It is used in combination with several other elements to provide
information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
customerInfo

Attributes:
None
Child Elements:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

516
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.178 encryptedAccountNumber

The encryptedAccountNumber element is an optional child of the registerTokenRequest element.

Use this element to provide the encrypted card account number. You must also supply the
encryptionKeyId element, so we can decrypt the account number.
Type = String; minLength = 1; maxLength = 1028

NOTE: Use of this element requires specific enablement. Please consult your Relationship
Manager or Implementation Consultant for additional information about this element and associated
feature.

Parent Elements:
registerTokenRequest

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

517
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.179 encryptedCardValidationNum

The encryptedCardValidationNum element is an optional child of the registerTokenRequest

element. Use this element to provide the encrypted card validation number. You must also supply the
encryptionKeyId element, so we can decrypt the validation number.
Type = String; minLength = 1; maxLength = 1028

NOTE: Use of this element requires specific enablement. Please consult your Relationship
Manager or Implementation Consultant for additional information about this element and associated
feature.

Parent Elements:
registerTokenRequest

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

518
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.180 encryptedTrack

The encryptedTrack element is a required child of the mpos element. This element provides the
encrypted track data resulting from a card swipe using a ROAM device.
Type = String; minLength = 1; maxLength = 1028

Parent Elements:
mpos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

519
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.181 encryptionKeyId

The encryptionKeyId element is an optional child of the registerTokenRequest element. Use this
element to provide the Id of the encryption key used to encrypt the account number and/or the card
validation number.
Type = String; minLength = 1; maxLength = 25

Parent Elements:
registerTokenRequest

Attributes:
None
Child Elements:
None

4.181.1 Obtaining a Public Encryption Key

To obtain the public key for the encryption of the account number and validation number, as well as the
key Id, access this URL: https://request.eprotect.vantivcnp.com/eProtect/keys.json. The link displays
information similar to the following:
{"publicKey":
{"modulus":"994fcf3844126afe2205a022b4a61b6f79cee12278ad7a8ce858762abf3976eeaa0c3e9a7a4
e5d2f61f8eb4297330d4f8e32befc1ab9518a93d015444ae90735913a939cb9b93800b623b709706c708574
5dfc79afa0f84b7a888ae80efa2794b08437dbe7835460bf1a9298fb43942aefb8b559863e1b2d18b16d78c
590c9375dfe12af84a7b1f506fcb6d91f8aa982102b400c62f8b306b619988b61363f540eab940029ed7a1a
64d9d99d4caf9aff847defe7385a4ade12b060dcfb6461adcba1f1e3e70cfd40e6032f1029146c79e793b47
bebf53b8c04a256aa6ad0f5b1900d956800719aea6a092e28ff4f033cd85e0e668f6577d126d2c8421abb40
f5","exponent":"10001","keyId":"29157300046"},"visaCheckout":{"apiKey":"WPKSQ4SVKENZW38
OQJ0S14Vg8m6kpdvHrRPzD-Ch4tXQ429zs"}}
The key rotates daily, but you can use each key for up to one year. Use the key and RSA-OAEP_SHA-1
encryption, encrypt the card and validation numbers. Use the keyId value as the value for the
encryptionKeyId element in your registerTokenRequest.

NOTE: The URLs for the Pre-Live environment is:

• Pre-Live - https://request.eprotect.vantivprelive.com/eProtect/keys.json

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

520
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.182 endDate

The endDate element is a optional child of both the createAddOn and createDiscount element,
where it specifies either the ending date of the Add On charge or the ending date of the discount.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
createAddOn, createDiscount

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

521
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.183 endingBalance

The endingBalance element is an optional child of the giftCardResponse element. It defines the
available balance on the submitted Gift Card after the requested operation.

NOTE: Although included in the schema, the beginningBalance, endingBalance, and

cashBackAmount elements are not currently supported.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
giftCardResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

522
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.184 endpoint

The endpoint element is a required child of the networkResponse element. It defines the card
network (i.e., Visa, Mastercard, Discover, or American Express) acting as an endpoint for the submitted
transaction.
Type = String; minLength = N/A; maxLength = 256

Parent Elements:
networkResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

523
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.185 enhancedAuthResponse

The enhancedAuthResponse element is an optional child of both the authorizationResponse and

saleResponse elements. Through its child elements, it can provide information concerning whether the
card used for the transaction is Prepaid and if so, the available balance. Depending upon the card used,
other elements can indicate affluence, card product type, prepaid card type, reloadability and whether or
not it is a virtual account number.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None

Child Elements: (all Optional)

fundingSource, affluence, issuerCountry, cardProductType, virtualAccountNumber, networkResponse,
accountRangeId

Example: enhancedAuthResponse - with fundingSource

<enhancedAuthResponse>
<fundingSource>
<type>PREPAID</type>
<availableBalance>0</availableBalance>
<reloadable>YES|NO|UNKNOWN</reloadable>
<prepaidCardType>GIFT</prepaidCardType>
</fundingSource>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

Example: enhancedAuthResponse - with affluence

<enhancedAuthResponse>
<affluence>AFFLUENT</affluence>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

Example: enhancedAuthResponse - with issuerCountry

<enhancedAuthResponse>
<issuerCountry>MEX</issuerCountry>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

524
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: enhancedAuthResponse - with cardProductType

<enhancedAuthResponse>
<cardProductType>CONSUMER</cardProductType>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

Example: enhancedAuthResponse - with virtualAccountNumber

<enhancedAuthResponse>
<virtualAccountNumber>true or false</virtualAccountNumber>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

Example: enhancedAuthResponse - with networkResponse

<enhancedAuthResponse>
<networkResponse>
<endpoint>VISA</endpoint>
<networkField fieldNumber="4" fieldName="Transaction Amount">
<fieldValue>000000000962</fieldValue>
</networkField>
<networkField fieldNumber="44" fieldName="Additional Response Data">
<networkSubField fieldNumber="0">
<fieldValue></fieldValue>
</networkSubField>
<networkSubField fieldNumber="1">
<fieldValue>5</fieldValue>
</networkSubField>
</networkField>
</networkResponse>
<accountRangeId>1234567890123456789</accountRangeId>
</enhancedAuthResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

525
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.186 enhancedData

The enhancedData element allows you to specify extra information concerning a transaction in order to
qualify for certain purchasing interchange rates. The following tables provide information about required
elements you must submit to achieve Level 2 or Level 3 Interchange rates for Visa and Mastercard.
• For Mastercard:
– The transaction must be taxable.
– The tax charged must be between 0.1% and 30% of the transaction amount, except as noted
bellow.
– For Level 3, the transaction must use a corporate, business, or purchasing card.

NOTE: You can qualify for Mastercard Level 2 rates without submitting the total tax amount (submit
0) if your MCC is one of the following: 4111, 4131, 4215, 4784, 8211, 8220, 8398, 8661, 9211,
9222, 9311, 9399, 9402.
This also applies to Level 3, regardless of your MCC (i.e., submission of 0 allowed).

– You must include at least one line item with amount, description, and quantity defined.

TABLE 4-1 Mastercard Level 2/Level 3 Data Requirements

cnpAPI Element (child of

Mastercard Level 2 Data Mastercard Level 3 Data enhancedData unless noted)

Customer Code (if Customer Code (if customerReference

supplied by customer) supplied by customer)

Card Acceptor Tax ID Card Acceptor Tax ID cardAcceptorTaxId (child of

detailTax)

Total Tax Amount Total Tax Amount salesTax

Product Code productCode (child of lineItemData)

Item Description itemDescription (child of

lineItemData)

Item Quantity quantity (child of lineItemData)

Item Unit of Measure unitOfMeasure (child of

lineItemData)

Extended Item Amount lineItemTotal (child of lineItemData)

or
lineItemTotalWithTax (child of
lineItemData)

In addition to the requirements below, please be aware of the following:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

526
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

• For Visa:
– The transaction must be taxable.
– The tax charged must be between 0.1% and 22% of the transaction amount, except as noted.
– For Level 3, the transaction must use a a corporate or purchasing card.

NOTE: Sales Tax is no longer required for Level 3. In this case omit the <salesTax > element
entirely.

TABLE 4-2 Visa Level 2/Level 3 Data Requirements

cnpAPI Element (child of

Visa Level 2 Data Visa Level 3 Data enhancedData unless noted)

Sales Tax Sales Tax* salesTax

Discount Amount discountAmount

Freight/Shipping Amount shippingAmount

Duty Amount dutyAmount

Item Sequence Number itemSequenceNumber (child of

lineItemData)

Item Commodity Code commodityCode (child of

lineItemData)

Item Description itemDescription (child of

lineItemData)

Product Code productCode (child of lineItemData)

Quantity quantity (child of lineItemData)

Unit of Measure unitOfMeasure (child of

lineItemData)

unit Cost unitCost (child of lineItemData)

Discount per Line Item itemDiscountAmount (child of

lineItemData)

Line Item Total lineItemTotal (child of lineItemData)

* Sales Tax is no longer required for Level 3. In this case omit the <salesTax > element entirely.

NOTE: For Discover transactions, the interchange rate is not impacted by the presence of Level 2
or Level 3 data.

Parent Elements:
authorization, capture, captureGivenAuth, credit, forceCapture, sale

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

527
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Child Elements: (all Optional)

customerReference, salesTax, deliveryType, taxExempt, discountAmount, shippingAmount, dutyAmount,
shipFromPostalCode, destinationPostalCode, destinationCountryCode, invoiceReferenceNumber,
orderDate, detailTax, lineItemData

Example: enhancedData Structure

<enhancedData>
<customerReference>Customer Reference</customerReference>
<salesTax>Amount of Sales Tax Included in Transaction</salesTax>
<deliveryType>TBD</deliveryType>
<taxExempt>true or false</taxExempt>
<discountAmount>Discount Amount Applied to Order</discountAmount>
<shippingAmount>Amount to Transport Order</shippingAmount>
<dutyAmount>Duty on Total Purchase Amount</dutyAmount>
<shipFromPostalCode>Ship From Postal Code</shipFromPostalCode>
<destinationPostalCode>Ship To Postal Code</destinationPostalCode>
<destinationCountryCode>Ship To ISO Country Code</destinationCountryCode>
<invoiceReferenceNumber>Merchant Invoice Number</invoiceReferenceNumber>
<orderDate>Date Order Placed</orderDate>
<detailTax>
<taxIncludedInTotal>true or false</taxIncludedInTotal>
<taxAmount>Additional Tax Amount</taxAmount>
<taxRate>Tax Rate of This Tax Amount</taxRate>
<taxTypeIdentifier>Tax Type Enum</taxTypeIdentifier>
<cardAcceptorTaxId>Tax ID of Card Acceptor</cardAcceptorTaxId>
</detailTax>
<lineItemData>
<itemSequenceNumber>Line Item Number within Order</itemSequenceNumber>
<itemDescription>Description of Item</itemDescription>
<productCode>Product Code of Item</productCode>
<quantity>Quantity of Item</quantity>
<unitOfMeasure>Unit of Measurement Code</unitOfMeasure>
<taxAmount>Sales Tax or VAT of Item</taxAmount>
<lineItemTotal>Total Amount of Line Item</lineItemTotal>
<lineItemTotalWithTax>taxAmount + lineItemTotal</lineItemTotalWithTax>
<itemDiscountAmount>Discount Amount</itemDiscountAmount>
<commodityCode>Card Acceptor Commodity Code for Item</commodityCode>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

528
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<unitCost>Price for One Unit of Item</unitCost>

</lineItemData>
</enhancedData>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

529
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.187 entryMode

The entryMode element is a required child of the pos element, which describes the method used for
card data entry at the point of sale.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
pos

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

notused terminal not used

keyed card number manually entered

track1 track 1 read

track2 magnetic stripe read (track 2 when known or when the terminal makes
no distinction between tracks 1 and 2.)

completeread complete magnetic stripe read and transmitted

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

530
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.188 ephemeralPublicKey

The ephemeralPublicKey element is a required child of the header element and provides the
BASE64 Encoded string of the ephemeral public key bytes from the Apple Pay transaction.
Type = Base 64 Encoded String; minLength = N/A; maxLength = 400

Parent Elements:
header

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

531
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.189 eventType

The eventType element is an optional child of the fraudCheck element and defines the type of event
occurring (see Enumeration table below).
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
fraudCheck

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Event Description

payment purchasing of goods/services (default, if no eventType specified)

login user logging into the account

account_creation the creation of a new account

details_changes user changing account details

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

532
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.190 expDate

The expDate element is a child of the card, token, paypage elements, which specifies the expiration
date of the card (format: mmyy) and is required for card-not-present transactions.

NOTE: Although the schema defines the expDate element as an optional child of the card, token
and paypage elements, you must submit a value for card-not-present transactions.

Type = String; minLength = 4; maxLength = 4

Parent Elements:
card, newCardInfo, newCardTokenInfo, originalCard, originalCardInfo, originalCardTokenInfo,
originalToken, paypage, token, updatedCard, updatedToken

Attributes:
None
Child Elements:
None

NOTE: You should submit whatever expiration date you have on file, regardless of whether or not it
is expired/stale.
We recommend all merchant with recurring and/or installment payments participate in the Account
Updater program.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

533
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.191 expMonth

The expMonth element is an optional child of the androidpayResponse element, which specifies the
month of expiration of the network token (format: mm).
Type = String; minLength = 2; maxLength = 2

Parent Elements:
androidpayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

534
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.192 expYear

The expYear element is an optional child of the androidpayResponse element, which specifies the
year of expiration of the network token (format: yyyy).
Type = String; minLength = 4; maxLength = 4

Parent Elements:
androidpayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

535
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.193 extendedCardResponse

The extendedCardResponse element is an optional child of the accountUpdater element, which

contains two child elements, code and message. The codes/messages can be any of the following:
• 500 - The account number was changed
• 501 - The Account Was Closed
• 502 - The expiration date was changed
• 504 - Contact the cardholder for updated information
• 507 - Cardholder has opted out of the update program

NOTE: When using Account Updater (any variation), you must always code to receive the
extendedCardResponse element and its children. We always return this information whenever
applicable regardless of whether you receive other account updater information in the transaction
response message.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
code, message

Example: newCardInfo Structure

<extendedCardResponse>
<message>Message for Code</message>
<code>500, 501, 502, 504, or 507</code>
</extendedCardResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

536
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.194 fastAccessFunding

The fastAccessFunding element is the parent element for the transaction type that a Payment
Facilitator or direct merchant uses to move funds to a sub-merchant/customer held debit card. Payment
Facilitators must use the fundingSubmerchantId and submerchantName elements. Direct merchants
must use the fundingCustomerId and customerName elements.

The transfer of funds occurs within 30 minutes.

NOTE: For additional information about PayFac Instruction-Based Dynamic Payout and the use of
this transaction type, please refer to the PayFac Instruction-Based Dynamic Payout document.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: amount, fundsTransferId, disbursementType, choice of fundingSubmerchantId or
fundingCustomerId, and choice of customerName or submerchantName, and choice of card, paypage, or
token

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

537
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.195 fastAccessFundingResponse

The fastAccessFundingResponse element is the parent element for information returned to you in
response to a fastAccessFunding transaction.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
submerchantCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message, postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

538
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.196 fieldValue

The fieldValue element is a child of both the networkField and networkSubField elements. The
fieldValue element is required when a child of the networkField element and no subfield exists.
This element is always required when used as a child of the networkSubField element. It provides the
raw data for the designated field, extracted from the network ISO 8583 response message.
Type = String; minLength = N/A; maxLength = 9999

Parent Elements:
networkField, networkSubField

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

539
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.197 filtering

The filtering element is an optional child of either the Authorization or Sale request transaction. You
use its child elements to selectively enable/disable the various Basic Fraud toolkit features. Setting either
the <international> or <chargeback> child element to false disables that filtering feature for the
transaction. The <prepaid> child can be set to true to enable the feature selectively, or set to false to
disable the feature for the transaction, if you elected to use the filter all prepaid configuration option.

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
Optional: prepaid, international, chargeback

NOTE: Although included in the schema and shown in the example below, the <chargeback>
element is not supported. To override the chargeback filter for a selected transaction, use the
fraudFilterOverride flag (see fraudFilterOverride on page 549). Please consult your Relationship
Manager for additional information.

Example: filtering Structure

<filtering>
<prepaid>true or false</prepaid>
<international>false</international>
<chargeback>false</chargeback>
</filtering>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

540
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.198 finalPayment

The fianlPayment element is a required child of the cnpInternalRecurringRequest. A value of

true indicates that this is the final payment of the subscription. Since this element is used only in internally
generated transaction, you do not need to code for its use.
Type = Boolean; Valid Values = true or false

Parent Elements:
cnpInternalRecurringRequest

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

541
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.199 fireSafetyIndicator

The fireSafetyIndicator element is an optional child of the lodgingInfo element and defines
whether or not the facility conforms to the requirements of the Hotel and Motel Fire Safety Act of 1990, or
similar legislation.
Type = Boolean; Valid Values = true or false

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

542
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.200 firstName

The firstName element is a child of the billtoAddress element, which specifies the first name of the
account holder and is required for echeckVerification transactions.

NOTE: When performing an eCheck Verification for a corporate account, you must include values
for the firstName and lastName elements. If you do not have the name of the check issuer, you
can use a value of unavailable for both elements.

Type = String; minLength = N/A; maxLength = 25

Parent Elements:
billToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

543
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.201 forceCapture

The forceCapture element is the parent element for all Force Capture transactions. These are
specialized Capture transactions used when you do not have a valid Authorization for the order, but have
fulfilled the order and wish to transfer funds. You can use this element in either Online or Batch
transactions.

NOTE: You must be authorized by Worldpay before processing this transaction type. In some
instances, using a Force Capture transaction can lead to chargebacks and fines.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored

back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the consumer.

minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant sub-group in
the user interface where this transaction will be displayed.
Please refer to Coding for Report Groups on page 10 for
additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, amount, orderSource, choice of card, token, mpos, paypage, or applepay
Optional: billToAddress, customBilling, taxType, enhancedData, processingInstructions, pos,
merchantData, productCode, secondaryAmount, surchargeAmount, debtRepayment, processingType,
lodgingInfo, merchantCategoryCode

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

544
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.202 forceCaptureResponse

The forceCaptureResponse element is the parent element for information returned to you in response
to a Force Capture transaction. It can be a child of either a cnpOnlineResponse element or a
batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Force Capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, tokenResponse, accountUpdater, giftCardResponse, applepayResponse, location

NOTE: The postDate child element is returned only in responses to Online transactions.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

545
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.203 formatId

The formatId element is a required child of the mpos element. This element identifies the format of the
encrypted track submitted from the device.
Type = String; minLength = 1; maxLength = 1028

Parent Elements:
mpos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

546
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.204 fraudCheck

The fraudCheck element is the parent element for the standalone Advanced Fraud Check transaction.
You use this transaction type to retrieve the results of the Advanced Fraud Check tool without submitting
an Authorization or Sale transaction. You can use this element only in Online transactions.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: advancedFraudChecks
Optional: billToAddress, shipToAddress, amount, eventType, accountLogin, accountPasshash

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

547
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.205 fraudCheckResponse

The fraudCheckResponse element is the parent element for information returned to you in response to
a standalone Fraud Check transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Force Capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: advancedFraudResults, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

548
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.206 fraudFilterOverride

The fraudFilterOverride element is an optional child of both the authorization and the sale
elements. A setting of true will override (disable) all fraud filters for the submitted transaction.
Type = Boolean; Valid Values = true or false

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

549
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.207 fraudResult

The fraudResult element is an optional child of the authorizationResponse, the saleResponse

and the authInformation elements. It contains child elements defining any fraud checking results.

Parent Elements:
activateResponse, authorizationResponse, deactivateResponse, loadResponse, saleResponse,
unloadResponse, authInformation

Attributes:
None

Child Elements: (All Optional)

authenticationResult, avsResult, cardValidationResult, advancedAVSResult, advancedFraudResults

Example: fraudResult Structure

<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>N</cardValidationResult>
<authenticationResult>2</authenticationResult>
<advancedAVSResult>011</advancedAVSResult>
<advancedFraudResults>
<deviceReviewStatus>pass, fail, review, or unavailable</deviceReviewStatus>
<deviceReputationScore>Score from ThreatMetix</deviceReputationScore>
<triggeredRule>Triggered Rule_may occur multiple times</triggeredRule>
</advancedFraudResults>
</fraudResult>

NOTE: The <advancedAVSResults> element applies only to American Express transactions. Also,
you must be enabled specifically to use the Advanced AVS feature. Please consult your
Relationship Manager for additional information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

550
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.208 fundingCustomerId

The fundingCustomerId element is a required child of the funding instruction request transaction types
listed below, where it specifies the identifier of the customer whose funds the instruction moves.
Type = String; minLength = N/A; maxLength = 50

Parent Elements:
customerCredit, customerDebit, vendorCredit, vendorDebit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

551
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.209 fundingInstructionVoid

The fundingInstructionVoid element is the parent element for the transaction type that a Payment
Facilitator uses to void a submitted, but not yet processed funding instruction. You must submit the
fundingInstructionVoid transaction prior to your cutoff time on the same day you submitted the
instruction to be voided. This rule also applies to funding instructions submitted on weekends.

Parent Elements:
batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

552
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.210 fundingInstructionVoidResponse

The fundingInstructionVoidResponse element is the parent element for information returned to

you in response to a fundingInstructionVoid transaction.

Parent Elements:
batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
credit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
credit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
credit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

553
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.211 fundingSource

The fundingSource element is an optional child of the enhancedAuthResponse element. Through its
child elements, it provides information concerning whether the card used for the transaction is Prepaid,
Credit, Debit, or FSA and if Prepaid, the available balance, the type of prepaid card, and whether it is
reloadable.

Parent Elements:
enhancedAuthResponse

Attributes:
None

Child Elements:
Required: type, availableBalance, reloadable, prepaidCardType

Example: fundingSource Structure

<fundingSource>
<type>PREPAID</type>
<availableBalance>0</availableBalance>
<reloadable>YES|NO|UNKNOWN</reloadable>
<prepaidCardType>GIFT</prepaidCardType>
</fundingSource>

NOTE: The fundingSource element and its child elements, type and availableBalance are
associated with the Insights features (see Issuer Insights on page 24.)
Please consult your Relationship Manager for additional information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

554
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.212 fundingSubmerchantId

The fundingSubmerchantId element is a required child of each funding instruction request transaction
type, where it specifies the identifier of the sub-merchant whose funds the instruction moves.

NOTE: If you process transactions solely on the Worldpay platform or on both the Worldpay and
Worldpay eCommerce platforms, use the Worldpay-supplied Sub-merchant Merchant Id as the
value of the fundingSubmerchantId element.
If you process solely on the Worldpay eCommerce platform, use the eCommerce-supplied value
obtained, after creating the Sub-merchant, by submitting a Sub-Merchant Retrieval Request via the
Merchant Provisioner API as the value of the fundingSubmerchantId element.
Please refer to the Worldpay eComm PayFac API Reference Guide for additional information.

Type = String; minLength = N/A; maxLength = 50

Parent Elements:
payFacCredit, payFacDebit, physicalCheckCredit, physicalCheckDebit, reserveCredit, reserveDebit,
submerchantCredit, submerchantDebit, vendorCredit, vendorDebit, fastAccessFunding,
fastAccessFundingResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

555
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.213 fundsTransferId

The fundsTransferId element is a required child of each funding instruction request/response

transaction type, where it specifies the Payment Facilitator assigned identifier for the transaction. You
must use unique values for each transaction across your entire organization. The system mirrors this
identifier back in the response messages.
Type = String; minLength = N/A; maxLength = 36 (for all except fastAccessFunding and
fastAccessFundingResponse)
Type = String; minLength = N/A; maxLength = 16 (for fastAccessFunding and
fastAccessFundingResponse)

Parent Elements:
payFacCredit, payFacCreditResponse, payFacDebit, payFacDebitResponse, physicalCheckCredit,
physicalCheckCreditResponse, physicalCheckDebit, physicalCheckDebitResponse, reserveCredit,
reserveCreditResponse, reserveDebit, reserveDebitResponse, submerchantCredit,
submerchantCreditResponse, submerchantDebit, submerchantDebitResponse, vendorCredit,
vendorCreditResponse, vendorDebit, vendorDebitResponse, fastAccessFunding,
fastAccessFundingResponse, customerCreditResponse, customerDebitResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

556
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.214 giftCardAuthReversal

The giftCradAuthReversal element is the parent element for the transaction type that reverses an
authorization on a Gift Card.

Parent Elements:
cnpOnlineRequest, cnpRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

557
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.215 giftCardAuthReversalResponse

The giftCardAuthReversalResponse element is the parent element for information returned to you
in response to a Gift Card Auth Reversal transaction.

Parent Elements:
cnpOnlineResponse, cnpResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Force Capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: postDate (returned for online transactions only), location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

558
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.216 giftCardBin

The giftCardBin element is a required child of the virtualGiftCard element defining the requested
BIN of the virtual Gift Card number requested.

NOTE: In an early iteration of schema V8.22 issued in September of 2013 this element was defined
as an optional child of the virtualGiftCard element. If you coded to the earlier version, be
aware that this element is now required. If you do not include this element, the transaction will fail
XML validation.

Type = String; minLength = N/A; maxLength = 10

Parent Elements:
virtualGiftCard

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

559
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.217 giftCardCapture

The giftCardCapture element is the parent element for the transaction type that captures funds
previously authorized on a Gift Card.

Parent Elements:
cnpOnlineRequest, cnpRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, captureAmount, originalRefCode, originalAmount, originalTxnTime,
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

560
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.218 giftCardCaptureResponse

The giftCardCaptureResponse element is the parent element for information returned to you in
response to a Gift Card Capture transaction.

Parent Elements:
cnpOnlineResponse, cnpResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Force Capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: fraudResult, postDate (returned for online transactions only), location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

561
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.219 giftCardCredit

The giftCardCredit element is the parent element for all Gift Card Credit transactions. There are two
possible structures for this message type. You use the first structure for credit transactions against
captures/sales processed by Worldpay. The alternate structure applies to credits against captures/sales
not processed by Worldpay. You can use this transaction type in either Online or Batch submissions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
For credits to transactions processed by Worldpay (Required): creditAmount, card
For credits to transactions processed by Worldpay (Optional): cnpTxnId
For credits to transactions not processed by Worldpay (Required): orderId, creditAmount, orderSource,
card

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

562
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.220 giftCardCreditResponse

The giftCardCreditResponse element is the parent element for information returned to you in
response to a Gift Card Credit transaction.

Parent Elements:
cnpOnlineResponse, cnpResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Force Capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Force Capture transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: fraudResult, postDate (returned for online transactions only), location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

563
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.221 giftCardResponse

The giftCardResponse element is a required child of several transaction types and optional for several
others. Through its child elements, it provides details about the available balance on a Gift Card, as well
as additional reference items used in subsequent, related transactions. For example, in a
giftCardAuthReversal transaction, you must include values of the refCode, systemTraceId, and
sequenceNumber from the authorizationResponse in the originalRefCode,
originalSystemTraceId, and originalSequenceNumber elements respectively.

Parent Elements:
Required:activateResponse, activateReversalResponse, giftCardAuthReversalResponse,
balanceInquiryResponse, giftCardCaptureResponse, giftCardCreditResponse, deactivateResponse,
deactivateReversalResponse, depositReversalResponse, loadResponse, loadReversalResponse,
refundReversalResponse, unloadResponse, unloadReversalResponse
Optional (per schema, but always returned for Gift Card Transactions): authorizationResponse,
captureGivenAuthResponse, forceCaptureResponse, saleResponse

Attributes:
None

Child Elements (All Optional, but must contain at least one child):
Optional: txnTime, refCode, systemTraceId, sequenceNumber, availableBalance, beginningBalance,
endingBalance, cashBackAmount

NOTE: Although included in the schema, the beginningBalance, endingBalance, and

cashBackAmount elements are not currently supported.

Example: giftCardResponse Structure

<giftCardResponse>
<txnTime>2016-11-15T12:00:00</txnTime>
<refCode>abc123</refCode>
<systemTraceId>123456</systemTraceId>
<sequenceNumber>123456</sequenceNumber>
<availableBalance>Balance Available on Gift Card</availableBalance>
</giftCardResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

564
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.222 giropay

The giropay element is a child of the sale transaction that, through its child elements, defines
information needed to process an Giropay (Real-time Bank Transfer) transaction. At this time, you can
use the iDeal method of payment in Online transactions only.

NOTE: Although included in the schema, this API no longer supports the Giropay alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about
Giropay support.

Parent Elements:
sale

Attributes:
None

Child Elements:
Optional: preferredLanguage

Example: giropay Structure

<giropay>
<preferredLanguage>Country Code of Language</preferredLanguage>
</giropay>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

565
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.223 giropayResponse

The giropayResponse element is a child of the saleResponse transaction when the method of
payment in the request is giropay. It contains child elements that you should store for future
use/reference.

NOTE: Although included in the schema, this API no longer supports the Giropay alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

Parent Elements:
saleResponse

Attributes:
None

Child Elements (all Optional):

paymentPurpose, redirectUrl, redirectToken

Example: giropayResponse Structure

<giropayResponse>
<redirectUrl>URL of Vantiv Supplied Mandate</redirectUrl>
<redirectToken>Map Mandate to cnpTxnId</redirectToken>
<paymentPurpose>Reference Number + Billing Descriptor</paymentPurpose>
</giropayResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

566
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.224 header

The header element is a required child of the applepay element. Its child elements provides information
required to process the Apple Pay transaction.
Type = String; minLength = N/A; maxLength = 10000

Parent Elements:
applepay

Attributes:
None

Child Elements (All Optional, but must contain at least one child):
Optional: applicationData, ephemeralPublicKey, publicKeyHash, transactionId

Example: header Structure

<header>Password</header>
<applicationData>SHA-256 Hash Hex Encoded of App Data Property</applicationData>
<ephemeralPublicKey>Base64 Encoded Ephemeral Public Key</ephemeralPublicKey>
<publicKeyHash>Base64 Hash of Public Key Bytes from Merchant
Certtificate</publicKeyHash>
<transactionId>Hex Transaction Id</transactionId>
</header>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

567
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.225 healthcareAmounts

The healthcareAmount element is a required child of the healthcareIIAS element. Through its child
elements, it provides details about the dollar amount and type of IIAS qualified items purchased using
Healthcare Prepaid cards.
For all card brands except Visa, the value you use for the totalHealthcareAmount child must be the
sum of the values applied to the following elements: RxAmount, visionAmount, clinicOtherAmount,
and dentalAmount. For Visa, do not include the visionAmount in the total.

Parent Elements:
healthcareIIAS

Attributes:
None

Child Elements:
Required: totalHealthcareAmount
Optional: RxAmount, visionAmount, clinicOtherAmount, dentalAmount

Example: fundingSource Structure

<healthcareAmounts>
<totalHealthcareAmount>Total of Healthcare Items</totalHealthcareAmount>
<RxAmount>Amount for Medications</RxAmount>
<visionAmount>Amount for Vision Items</visionAmount>
<clinicOtherAmount>Amount for Clinic Charges</clinicOtherAmount>
<dentalAmount>Amount for Dental Charges</dentalAmount>
</healthcareAmounts>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

568
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.226 healthcareIIAS

The healthcareIIAS element is an optional child of Authorization and Sale transactions. Through its
child elements, it provides information about IIAS qualified items purchased using Healthcare Prepaid
cards.

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
Required: healthcareAmounts, IIASFlag

Example: fundingSource Structure

<healthcareIIAS>
<healthcareAmounts>
<totalHealthcareAmount>Total of Healthcare Items</totalHealthcareAmount>
<RxAmount>Amount for Medications</RxAmount>
<visionAmount>Amount for Vision Items</visionAmount>
<clinicOtherAmount>Amount for Clinic Charges</clinicOtherAmount>
<dentalAmount>Amount for Dental Charges</dentalAmount>
</healthcareAmounts>
<IIASFlag>Y</IIASFlag>
</healthcareIIAS>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

569
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.227 hotelFolioNumber

The hotelFolioNumber element is an optional child of the lodgingInfo element and defines
customer folio number from your system.
Type = String; minLength = N/A; maxLength = 17

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

570
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.228 iban

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The iban element is a required child of the sepaDirectDebit element. It defines the International
Bank Account Number of the customer.
Type = String; minLength = 15; maxLength = 34

Parent Elements:
sepaDirectDebit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

571
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.229 ideal

The ideal element is a child of the sale transaction that, through its child elements, defines information
needed to process an iDEAL (Real-time Bank Transfers) transaction. At this time, you can use the iDEAL
method of payment in Online transactions only.

NOTE: Although included in the schema, this API no longer supports the iDEAL alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about iDEAL
support.

Parent Elements:
sale

Attributes:
None

Child Elements:
Optional: preferredLanguage

Example: ideal Structure

<ideal>
<preferredLanguage>Country Code of Language</preferredLanguage>
</ideal>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

572
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.230 idealResponse

The idealResponse element is a child of the saleResponse transaction when the method of payment
in the request is ideal. It contains child elements that you should store for future use/reference.

NOTE: Although included in the schema, this API no longer supports the iDeal alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

Parent Elements:
saleResponse

Attributes:
None

Child Elements (all Optional):

paymentPurpose, redirectUrl, redirectToken

Example: idealResponse Structure

<idealResponse>
<redirectUrl>URL of Vantiv Supplied Mandate</redirectUrl>
<redirectToken>Map Mandate to cnpTxnId</redirectToken>
<paymentPurpose>Reference Number + Billing Descriptor</paymentPurpose>
</idealResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

573
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.231 IIASFlag

The IIASFlag element is a required child of the healthcareIIAS element. This element only supports
a value of Y.
Type = String (enum); minLength = N/A; maxLength = 1; Valid Value = Y

Parent Elements:
healthcareIIAS

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

574
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.232 incomeAmount

The incomeAmount element is an optional child of the customerInfo element and defines the yearly
income of the customer. It is used in combination with several other elements to provide information for
some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Long; minLength = N/A; maxLength = N/A

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

575
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.233 incomeCurrency

The incomeCurrency element is an optional child of the customerInfo element and defines the
currency of the incomeAmount element. The default value is USD (United States Dollars). It is used in
combination with several other elements to provide information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

Enumerations:

Enumeration Description

AUD Australian Dollar

CAD Canadian Dollar

CHF Swiss Francs

DKK Denmark Kroner

EUR Euro

GBP United Kingdom Pound

HKD Hong Kong Dollar

JPY Japanese Yen

NOK Norwegian Krone

NZD New Zealand Dollar

SEK Swedish Kronor

SGD Singapore Dollar

USD (default) United States Dollar

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

576
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.234 international

The international element is an optional child of the filtering element. To disable the filtering
operation for a selected transaction include the international element with a setting of false.
Type = Boolean; Valid Value = false

Parent Elements:
filtering

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

577
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.235 intervalType

The intervalType element is a required child of the createPlan element and defines the billing period
associated with the Plan.
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
createPlan

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

ANNUAL The billing period is once per year.

SEMIANNUAL The billing period is twice per year.

QUARTERLY The billing period is every three months.

MONTHLY The billing period is every month.

WEEKLY The billing period is every week.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

578
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.236 invoiceReferenceNumber

The invoiceReferenceNumber element is an optional child of the enhancedData element, which

specifies the merchant’s invoice number. If you do not know the invoice number, do not include this
element.
Type = String; minLength = 1; maxLength = 15

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

579
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.237 issuerCountry

The issuerCountry element is an optional child of the enhancedAuthResponse element, which

defines the country of the bank that issued the card submitted in the Authorization or Sale transaction.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
enhancedAuthResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

580
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.238 itemDescription

The itemDescription element is a required child of the lineItemData element, which provides a
brief text description of the item purchased.
Type = String; minLength = N/A; maxLength = 26

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

581
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.239 itemDiscountAmount

The itemDiscountAmount element is an optional child of the lineItemData element, which specifies
the item discount amount. Although an optional element, it is required by Visa for Level III Interchange
rates. The value must be greater than or equal to 0. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

582
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.240 itemSequenceNumber

The itemSequenceNumber element is an optional child of the lineItemData element (required for
Visa transactions). When providing line item data, you must number each item sequentially starting with
1.
Type = Integer; minInclusive value = 1, maxInclusive value = 99

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

583
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.241 ksn

The ksn element is a required child of the mpos element. This element defines the Key serial Number
returned from the encrypting device. It is created automatically from the unique identifier of the device and
an internal transaction counter.
Type = String; minLength = 1; maxLength = 1028

Parent Elements:
mpos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

584
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.242 lastName

The lastName element is a child of the billtoAddress element, which specifies the last name of the
account holder and is required for echeckVerification transactions.

NOTE: When performing an eCheck Verification for a corporate account, you must include values
for the firstName and lastName element. If you do not have the name of the check issuer, you
can use a value of “unavailable” for both elements.

Type = String; minLength = N/A; maxLength = 25

Parent Elements:
billToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

585
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.243 lineItemData

The lineItemData element contains several child elements used to define information concerning
individual items in the order. Although the schema defines it as an optional child of the enhancedData
element, it is required for Level III interchange rates.

NOTE: Mastercard and Visa allow up to 99 instances of this element in a transaction. American
Express allows a maximum of 4 instances of this element in a transaction.

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
Required: itemDescription
Optional: itemSequenceNumber, productCode, quantity, unitOfMeasure, taxAmount, lineItemTotal,
lineItemTotalWithTax, itemDiscountAmount, commodityCode, unitCost, detailTax

NOTE: When including the lineItemData element, please be aware of the following rules for its child
elements:
• itemSequenceNumber is required by Visa
• productCode, quantity, unitOfMeasure, and lineItemTotal are required by Visa and
Mastercard
• itemDiscountAmount, commodityCode, and unitCost are required by Visa for Level III
Interchange rates

Example: lineItemData Structure

<lineItemData>
<itemSequenceNumber>Line Item Number within Order</itemSequenceNumber>
<itemDescription>Description of Item</itemDescription>
<productCode>Product Code of Item</productCode>
<quantity>Quantity of Item</quantity>
<unitOfMeasure>Unit of Measurement Code</unitOfMeasure>
<taxAmount>Sales Tax or VAT of Item</taxAmount>
<lineItemTotal>Total Amount of Line Item</lineItemTotal>
<lineItemTotalWithTax>taxAmount + lineItemTotal</lineItemTotalWithTax>
<itemDiscountAmount>Discount Amount</itemDiscountAmount>
<commodityCode>Card Acceptor Commodity Code for Item</commodityCode>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

586
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<unitCost>Price for One Unit of Item</unitCost>

<detailTax>
<taxIncludedInTotal>true or false</taxIncludedInTotal>
<taxAmount>Additional Tax Amount</taxAmount>
<taxRate>Tax Rate of This Tax Amount</taxRate>
<taxTypeIdentifier>Tax Type Enum</taxTypeIdentifier>
<cardAcceptorTaxId>Tax ID of Card Acceptor</cardAcceptorTaxId>
</detailTax>
</lineItemData>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

587
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.244 lineItemTotal

The lineItemTotal element is an optional child of the lineItemData element, which specifies the
total cost of the line items purchased, not including tax. For example, if the order was for 500 pencils at
$1.00 each, the lineItemTotal would be $500. Although an optional element, it is required by Visa and
Mastercard when specifying line item data. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

588
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.245 lineItemTotalWithTax

The lineItemTotalWithTax element is an optional child of the lineItemData element, which

specifies the total cost of the line items purchased including tax. If the tax is not known, do not include this
element. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

589
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.246 load

The load element is the parent element for the transaction type that adds funds to a reloadable Gift
Card.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (all Required)

orderId, amount, orderSource, card

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

590
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.247 loadResponse

The loadResponse element is the parent element for information returned to you in response to a load
transaction. It can be a child of either a cnpOnlineResponse element or a batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Load transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Load transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Load transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, fraudResult, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

591
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.248 loadReversal

The loadReversal element is the parent element for the transaction type that reverses the loading of a
Gift Card.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

592
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.249 loadReversalResponse

The loadReversalResponse element is the parent element for information returned to you in response
to an loadReversal transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Load Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Load Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Load Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

593
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.250 location

The location element is an optional child of all response messages and designates which data center
processed the transaction. This element only applies to merchant using our Multi-Site processing option.
Type = String minLength = N/A; maxLength = N/A

Parent Elements:
activateResponse, activateReversalResponse, authorizationResponse, authReversalResponse,
balanceInquiryResponse, cancelSubscriptionResponse, captureGivenAuthResponse, captureResponse,
createPlanResponse, deactivateResponse, deactivateReversalResponse, depositReversalResponse,
creditResponse, echeckCreditResponse, echeckRedepositResponse, echeckSalesResponse,
echeckVerificationResponse, echeckVoidResponse, forceCaptureResponse,
fundingInstructionVoidResponse, fraudCheckResponse, giftCardAuthReversalResponse,
giftCardCaptureResponse, giftCardCreditResponse, loadResponse, loadReversalResponse,
queryTransactionResponse, queryTransactionUnavailableResponse, refundReversalResponse,
registerTokenResponse, saleResponse, unloadResponse, unloadReversalResponse,
updateCardValidationNumOnTokenResponse, voidResponse, updatePlanResponse,
updateSubscriptionResponse, fastAccessFundingResponse, payFacCreditResponse,
payFacDebitResponse, physicalCheckCreditResponse, physicalCheckDebitResponse,
reserveCreditResponse, reserveDebitResponse, submerchantCreditResponse,
submerchantDebitResponse, vendorCreditResponse, vendorDebitResponse, customerCreditResponse,
customerDebitResponse, payoutOrgCerditResponse, payoutOrgDebitResponse,
translateToLowValueTokenResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

594
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.251 lodgingCharge

The lodgingCharge element is an optional child of the lodgingInfo element and through its child
element, defines the type of additional charges associated with the stay of the guest. You can include this
element a maximum of six times in a transaction.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
lodgingInfo

Attributes:
None
Child Elements:
name

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

595
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.252 lodgingInfo

The lodgingInfo element, through its child elements, defines a number of lodging related data points
that, when submitted, can result in a more favorable interchange rate (see Table 4-3 for additional
information).

Parent Elements:
authorization, capture, captureGivenAuth, credit, forceCapture, sale

Attributes:
None

Child Elements: (all Optional)

hotelFolioNumber, checkInDate, checkOutDate, duration, customerServicePhone, programCode,
roomRate, roomTax, numAdults, propertyLocalPhone, fireSafetyIndicator, lodgingCharge

Example: lodgingInfo Structure

<lodgingInfo>
<hotelFolioNumber>Customer Folio Number</hotelFolioNumber>
<checkInDate>YYYY-MM-DD</checkInDate>
<checkOutDate>YYYY-MM-DD</checkOutDate>
<duration>Length of Stay</duration>
<customerServicePhone>CS Phone Number</customerServicePhone>
<programCode>Program Code Enum</programCode>
<roomRate>Daily Cost of Room</roomRate>
<roomTax>Room Taxes</roomTax>
<numAdults>Number of Adult Guests</numAdults>
<propertyLocalPhone>Local Phone Number of Facility</propertyLocalPhone>
<fireSafetyIndicator>true or false</fireSafetyIndicator>
<lodgingCharge>
<name>Lodging Charge Enum</name>
</lodgingCharge>
</lodgingInfo>

TABLE 4-3 Element Requirements for Interchange Optimization

cnpAPI Element Card Brand Requirement for Better Interchange

hotelFolioNumber • Required for all card brands

checkInDate • Required for all card brands

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

596
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

TABLE 4-3 Element Requirements for Interchange Optimization

cnpAPI Element Card Brand Requirement for Better Interchange

checkOutDate • Required for all card brands

duration • Required for Visa and Mastercard (total number of nights)
• Required for Discover (number of nights * number of rooms)
• Not required for American Express
customerServicePhone • Required for Visa Mastercard, and Discover
• Not required for American Express
programCode • Required for American Express
• Recommended for Visa, but not required for Interchange
roomRate • Required for Mastercard and Discover
• Not Required for Visa and American Express
roomTax • Required for Visa and Mastercard (total number of nights)
• Required for Discover (number of nights * number of rooms)
numAdults • Required for Discover (total adults for all rooms booked)
• Not required for other card brands
propertyLocalPhone • Required for Mastercard
• Not required for other card brands
fireSafetyIndicator • Required for Mastercard
• Not required for other card brands
lodgingCharge • Required for Visa
• Not required for other card brands

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

597
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.253 mandateProvider

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The mandateProvider element is a required child of the sepaDirectDebit element and defines
whether the Merchant or Worldpay provides the mandate for customer approval.
Type = String (Enum); Allowed Values = Merchant or Vantiv

Parent Elements:
sepaDirectDebit

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

598
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.254 mandateReference

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The mandateReference element is an optional child of both the sepaDirectDebit element and the
sepaDirectDebitResponse element. You use this element for recurring payments (after the initial
transaction) to provide the reference number that links subsequent payments in a recurring stream to the
mandate agreed to at the time of the initial payment. Worldpay returns this value in the
sepaDirectDebitResponse associated with the initial payment. It is not returned for subsequent
payments in a recurring stream.
Type = String; minLength = N/A; maxLength = 256

Parent Elements:
sepaDirectDebit, sepaDirectDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

599
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.255 mandateSignatureDate

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The mandateSignatureDate element is an optional child of the sepaDirectDebit element and

defines the date the consumer agreed to the mandate allowing the merchant to debit their account.
Although optional, you should always provide this information when the value for the mandateProvider
element is Merchant.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
sepaDirectDebit

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

600
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.256 mandateURL

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The mandateUrl element is an optional child of the sepaDirectDebit element and defines the URL
of the mandate to which the consumer agreed, allowing the merchant to debit their account. Although
optional, you should always provide this information when the value for the mandateProvider element
is Merchant.
Type = String; minLength = 1; maxLength = 2000

Parent Elements:
sepaDirectDebit

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

601
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.257 matchCount

The matchCount element is a required child of the queryTransactionResponse element and

defines the number of found transactions that matched the criteria submitted in the queryTransaction.
Type = Integer; totalDigits = 2

Parent Elements:
queryTransactionResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

602
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.258 merchantCategoryCode

The merchantCategoryCode element is an optional child of several transaction types. This element
allows you to define the MCC used for this transaction from those white listed for your organization. If you
submit an MCC not on the white list, we decline the transaction with a Response Code of 170 - Submitted
MCC not allowed.
Type = String; minLength = 4; maxLength = 4

NOTE: Although included in the schema, this element is not yet available for general use. Please
speak to your Relationship Manager for additional information.

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

603
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.259 merchantData

The merchantData element is an optional child element of several transaction types. You can use its
children to track transactions based upon marketing campaigns, affiliates, or other user defined
parameter.

Parent Elements:
authorization, captureGivenAuth, credit, echeckCredit, echeckPreNoteCredit, echeckPreNoteSale,
echeckRedeposit, echeckSale, echeckVerification, forceCapture, sale

Attributes:
None
Child Elements (all optional):
affiliate, campaign, merchantGroupingId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

604
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.260 merchantGroupingId

The merchantGroupingId element is an optional child element of the merchantData element. You
can use it to track transactions based upon this user defined parameter.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
merchantData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

605
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.261 merchantId

The merchantId element is a child of the accountUpdateFileRequestData element used when you
request an Account Update file. This value is a unique string used to identify the merchant within the
system.
Type = String; minLength = N/A; maxLength = 50

Parent Elements:
accountUpdateFileRequestData

Attributes:
None

Child Elements:
None

NOTE: Several elements use merchantId as an attribute, including batchRequest,

batchResponse, and cnpOnlineRequest.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

606
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.262 message

The message element contains a brief definition of the response code returned for the transaction.
When it is a child of the extendedCardResponse element, the only values allowed are either "The
account was closed," or "Contact the cardholder for updated information."
For a complete list of response codes and associated messages, please refer to Appendix A.
Type = String; minLength = N/A; maxLength = 512

Parent Elements:
activateResponse, activateReversalResponse, authorizationResponse, captureResponse,
captureGivenAuthResponse, creditResponse, customerCreditResponse, customerDebitResponse,
deactivateResponse, deactivateReversalResponse, depositReversalResponse, echeckCreditResponse,
echeckPreNoteCreditResponse, echeckPreNoteSaleResponse, echeckRedepositResponse,
echeckSalesResponse, echeckVerificationResponse, echeckVoidResponse, extendedCardResponse,
forceCaptureResponse, fraudCheckResponse, loadResponse, loadReversalResponse,
queryTransactionResponse, queryTransactionUnavailableResponse, refundReversalResponse,
saleResponse, unloadResponse, unloadReversalResponse, voidResponse,
cancelSubscriptionResponse,updatePlanResponse, updateSubscriptionResponse,
payFacCreditResponse, payFacDebitResponse, physicalCheckCreditResponse,
physicalCheckDebitResponse, reserveCreditResponse, reserveDebitResponse,
submerchantCreditResponse, submerchantDebitResponse, vendorCreditResponse,
vendorDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

607
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.263 middleInitial

The middleInitial element is a child of the billtoAddress element, which specifies the middle
initial of the account holder. It is an optional element used for echeckVerification transactions.
Type = String; minLength = N/A; maxLength = 1

Parent Elements:
billToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

608
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.264 mpos

The mpos element defines payment card information when the transaction originates with a ROAM
device.

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale, registerTokenRequest

Attributes:
None

Child Elements: (all Required)

ksn, formatId, encryptedTrack, track1Status, track2Status

Example: mpos Structure

<mpos>
<ksn>Key Serial Number</ksn>
<formatId>Format of Encrypted Track</formatId>
<encrytpedTrack>Encrypted Track Data</encrytpedTrack>
<track1Status>Card Validation Number</track1Status>
<track2Status>Card Validation Number</track2Status>
</mpos>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

609
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.265 name

The name element has multiple uses depending upon the parent element. In both the billToAddress
and shipToAddress element structures, it defines the customer name. When used as a child of one of
the Recurring Engine associated parents (i.e., createAddOn, updateAddOn, createDiscount,
updateDiscount, or createPlan), the name element specifies the name of the parent item being
created/updated.
See the section below for the element definition when a child of lodgingCharge.
Type = String; minLength = N/A; maxLength = 100

Parent Elements:
billToAddress, shipToAddress, createAddOn, updateAddOn, createDiscount, updateDiscount, createPlan

NOTE: The name element is required for Direct Debit transactions. If you do not submit the
customer name in an Direct Debit transaction, we return Response Code 709 - Invalid Data.
The name element is required for sale transactions using the sepaDirectDebit method of
payment and must be a minimum of two characters. Failure to include the name element results in a
901 - Missing Name Response Code. If the value is not at least two characters, the transaction
declines with a response code of 902 - Invalid Name

Attributes:
None
Child Elements:
None

4.265.1 name as a child of lodgingCharge

The name element is an optional child of the lodgingCharge element and defines the type of additional
charges associated with the stay of the guest.

Parent Elements:
lodgingCharge

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

610
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Enumerations:

Enum Description

RESTAURANT There are additional charges associated with the use of the facility
restaurant.

GIFTSHOP There are additional charges associated with the use of the facility gift
shop

MINIBAR There are additional charges associated with the use of the room
minibar

TELEPHONE There are additional charges associated with the use of the room
telephone service.

LAUNDRY There are additional charges associated with the use of the facility
laundry service.

OTHER There are additional charges associated with the use of other
uncategorized facility services.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

611
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.266 networkField

The networkField element is an optional child of the networkResponse element. Its attributes and
child elements define the Field Number, Field Name, (Raw) Field Value, as well as any Sub-fields, if
applicable.

Parent Elements:
networkResponse

Attributes:

Attribute Name Type Required? Description

fieldName String Yes This attribute defines the name of the ISO 8583 field
containing the information returned.
Type = Enum
Allowed Values:
• Transaction Amount
• Settlement Date
• Authorization Identification Response
• Response Code
• Additional Response Data
• Private Use Additional Data
• Settlement Currency Code
• Cardholder Billing Currency Code
• Additional Amounts
• Reserved Private
• Transaction Description
• Reserved For National Use
• Reserved For Private Use

fieldNumber Integer Yes This attribute defines the number of the ISO 8583 field
containing the information returned. Different card
networks may use different Field Numbers for the
same information.
minLength = 1 maxLength = N/A

Child Elements:
fieldValue, networkSubField

Example: networkField Structure with fieldValue

<networkField fieldNumber="4" fieldName="Transaction Amount">
<fieldValue>000000001111</fieldValue>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

612
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

</networkField>

Example: networkField Structure with networkSubField

<networkField fieldNumber="44" fieldName="Additional Response Data">
<networkSubField fieldNumber="1">
<fieldValue>7</fieldValue>
</networkSubField>
<networkSubField fieldNumber="2">
<fieldValue>W</fieldValue>
</networkSubField>
</networkField>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

613
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.267 networkName

The networkName element defines the Debit Network through which Worldpay processed the
transaction. This element appears only if you use the Worldpay Prime PINless Debit service and
Worldpay routed the transaction through a Debit Network for approval.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
pinlessDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

614
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.268 networkResponse

The networkResponse element is an optional child of the enhancedAuthResponse element. Its child
elements provide a number of data points returned by the card networks in their ISO 8583 response
messages.

Parent Elements:
enhancedAuthResponse

Attributes:
None
Child Elements:
endpoint, networkField

Example: networkResponse Structure

<networkResponse>
<endpoint>VISA</endpoint>
<networkField fieldNumber="4" fieldName="Transaction Amount">
<fieldValue>000000000962</fieldValue>
</networkField>
<networkField fieldNumber="44" fieldName="Additional Response Data">
<networkSubField fieldNumber="1">
<fieldValue>7</fieldValue>
</networkSubField>
<networkSubField fieldNumber="2">
<fieldValue>W</fieldValue>
</networkSubField>
</networkField>
</networkResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

615
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.269 networkSubField

The networkSubField element is a required child of the networkField element, when a subfield
exists. Its child element provides the raw subfield data returned by the card networks in their ISO 8583
response messages.

Parent Elements:
networkField

Attributes:

Attribute Name Type Required? Description

fieldNumber Integer Yes This attribute defines the number of the ISO 8583 field
or subfield containing the information returned.
Different card networks may use different Field
Numbers for the same information.
minLength = 1 maxLength = N/A

Child Elements:
fieldValue

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

616
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.270 networkTransactionId

The networkTransactionId element is an optional child of the authorizationResponse, and

saleResponse transactions. Visa and Discover use this value to link subsequent payments in a
recurring/installment stream back to the initial transaction. You must include this value in the request
message (originalNetworkTransactionId element) for subsequent recurring payments, if the
payment method is either Visa or Discover. Worldpay recommends coding
Type = String; minLength = N/A; maxLength = 30

NOTE: In the initial transaction of the recurring/installment stream, you must set the
processingType element to either initialRecurring or initialInstallment, as applicable.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

617
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.271 newAccountInfo

The newAccountInfo element is an optional child of the accountUpdater element, which contains
child elements providing the updated information for the submitted account.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
accType, accNum, routingNum

Example: newAccountInfo Structure

<newAccountInfo>
<accType>Account Type</accType>
<accNum>New Account Number</accNum>
<routingNum>New Routing Number</routingNum>
</newAccountInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

618
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.272 newCardInfo

The newCardInfo element is an optional child of the accountUpdater element, which contains child
elements providing the updated information for the submitted card.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
type, number, expDate

Example: newCardInfo Structure

<newCardInfo>
<type>Card Type</type>
<number>New Account Number</number>
<expDate>New Expiration Date</expDate>
</newCardInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

619
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.273 newCardTokenInfo

The newCardTokenInfo element is an optional child of the accountUpdater element, which contains
child elements providing the updated token information for the submitted token.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
cnpToken, type, expDate, bin

Example: newCardInfo Structure

<newCardTokenInfo>
<cnpToken>New Token</cnpToken>
<type>Card Type</type>
<expDate>New Expiration Date</expDate>
<bin>New Card BIN</bin>
</newCardTokenInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

620
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.274 newTokenInfo

The newTokenInfo element is an optional child of the accountUpdater element, which contains child
elements providing the updated information for the submitted account. The system returns this
information when processing a tokenized Direct Debit transactions and a change (NOC) is found against
the account.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
accType, cnpToken, routingNum

Example: newAccountInfo Structure

<newTokenInfo>
<accType>Account Type</accType>
<cnpToken>New Token Number</cnpToken>
<routingNum>New Routing Number</routingNum>
</newTokenInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

621
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.275 nextRecycleTime

NOTE: The recycling Advice feature is no longer supported.

The nextRecycleTime element is an optional child of the recycleAdvice element, which specifies
the date and time (in GMT) recommended for the next recycle of the declined Authorization/Sale
transaction. The format of the element is YYYY-MM-DDTHH:MM:SSZ. For example,
2011-04-21T11:00:00Z.

NOTE: Per the ISO8601 standard, the Z appended to the end of the date/time stamp indicates the
time is GMT.

Type = dateTime; minLength = N/A; maxLength = 20

Parent Elements:
recycleAdvice

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

622
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.276 numAdults

The numAdults element is an optional child of the lodgingInfo element and defines the total number
of adult guests staying (or planning to stay) at the facility (i.e., all booked rooms).
Type = Integer; totalDigits = 2

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

623
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.277 number

The number element defines the account number associated with the transaction or the new/old account
number associated with an update. This is a required child of the card element for card-not-present
transactions.
Type = String; minLength = 13; maxLength = 25

Parent Elements:
accountInformation, card, newCardInfo, originalCardInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

624
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.278 numberOfPayments

The numberOfPayments element is defines the number of payments in a recurring billing plan including
the initial payment. The timing of subsequent charges is defined by the planCode element. This element
is an optional child of both the subscription, and createPlan elements. When submitted as a child
of the subscription element, the value overrides the default value defined in the Plan.

NOTE: For an open-ended Plan, please omit the optional numberOfPayments element in
createPlan.
For an open-ended subscription, please omit the optional numberOfPayments element in
subscription and reference an open-ended Plan.

Type = Integer; minLength = 1; maxLength = 99

Parent Elements:
subscription, createPlan

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

625
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.279 onlinePaymentCryptogram

The onlinePaymentCryptogram element is an optional child of the applepayResponse element and

provides the BASE64 Encoded signature cryptogram associated with the Apple Pay transaction.
Type = Base 64 Encoded String; minLength = N/A; maxLength = 56

Parent Elements:
applepayResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

626
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.280 orderDate

The orderDate element is an optional child of the enhancedData element, which specifies the date the
order was placed. If you do not know the order date, do not include this element.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

627
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.281 orderId

The orderId element is a required child of several transaction types and defines a merchant-assigned
value representing the order in the merchant’s system.
Type = String; minLength = N/A; maxLength = 25

NOTE: If you are using the orderId element as the transaction signature for the Recycling Engine,
do not use the pipe character ("|") in the orderId. Use of the pipe character in this scenario will cause
recycling errors.

Parent Elements:
accountUpdate, accountUpdateResponse, activate, authorization, authorizationResponse,
balanceInquiry, credit, captureGivenAuth, deactivate, echeckCredit, echeckPreNoteCredit,
echeckPreNoteSale, echeckSale, echeckVerification, forceCapture, giftCardCredit, load,
registerTokenRequest, sale, saleResponse, unload, updateCardValidationNumOnToken

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

628
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.282 orderSource

The orderSource element defines the order entry source for the type of transaction.
Type = Choice (enum); minLength = N/A; maxLength = N/A

Parent Elements:
activate, authorization, balanceInquiry, captureGivenAuth, credit, deactivate, echeckCredit,
echeckPreNoteCredit, echeckPreNoteSale, echeckSale, echeckVerification forceCapture, load, sale,
unload

Attributes:
None

Child Elements:
None

Enumerations:

NOTE: If you submit the wrong orderSource value, we return the response code 370 - Internal
System Error - Contact Vantiv.
eCheckSale transactions must use an orderSource of one of the following: telephone,
ecommerce, echeckppd, or recurringtel.

Enumeration Description

3dsAuthenticated Use this value only if you authenticated the cardholder via an approved 3DS
system such as Visa Verified By Visa, Mastercard SecureCode, or American
Express SafeKey.
NOTE: Worldpay must configure your Merchant Profile to process 3DS type
payments and accept this value.

3dsAttempted Use this value only if you attempted to authenticate the cardholder via an
approved 3DS system such as Visa Verified By Visa, Mastercard SecureCode, or
American Express SafeKey, but either the Issuer or cardholder is not participating
in the 3DS program. If this is a Mastercard or American Express transaction, you
must include the authenticationValue returned by the card brand.
NOTE: Worldpay must configure your Merchant Profile to process 3DS type
payments and accept this value.

echeckppd (Direct Debit only) Use this value for Direct Debit PPD transactions
(Prearranged Payment and Deposit Entries). This type of transaction occurs when
a merchants receives a written authorization, including a voided paper check,
from a consumer so that the merchant can debit the consumer account. These
transactions can be single entry or recurring debits to a consumer's account.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

629
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Enumeration Description

ecommerce The transaction is an Internet or electronic commerce transaction.

installment The transaction in an installment payment.

mailorder The transaction is for a single mail order transaction.

recurring The transaction is a recurring transaction. For Visa transactions, you can use this
value for all transactions in a recurring stream including the initial transaction.

retail The transaction is a Swiped or Keyed Entered retail purchase transaction.

telephone The transaction is for a single telephone order.

recurringtel (Direct Debit only) The transaction is a recurring Direct Debit transaction initiated
via telephone

applepay The transaction uses the Apple Pay service.

androidpay The transaction uses the Google Pay service.

NOTE: Worldpay supports values of recurring and installment, when using the Prime service. If
you send any other orderSource, Worldpay does not attempt Prime Routing. Please speak to your
Implementation Consultant for additional information about enabling the Prime Routing service.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

630
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.283 originalAccountInfo

The originalAccountInfo element is an optional child of the accountUpdater element, which

contains child elements providing the original information for the submitted account.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
accType, accNum, routingNum

Example: originalAccountInfo Structure

<originalAccountInfo>
<accType>Account Type</accType>
<cnpToken>Original Token Number</cnpToken>
<routingNum>Original Routing Number</routingNum>
</originalAccountInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

631
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.284 origAccountNumber

The origAccountNumber element is an optional child of the queryTransaction element and defines
the account number of the credit/debit/gift card used in the original transaction.

NOTE: If you are performing a query for an Direct Debit transaction, do not use this element to
designate the checking/savings account number. You should use this element for Credit/Debit/Gift
card account numbers only.

Type = String; minLength = 13; maxLength = 25

Parent Elements:
queryTransaction

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

632
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.285 origActionType

The origActionType element is a required child of the queryTransaction element and defines the
transaction type of original transaction.
Type = String (Enum); minLength = 1; maxLength = 2 (Valid values shown below)

Parent Elements:
queryTransaction

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Transaction Type

A authorization

AR activateReversal

D deposit or sale

G activate

I unload

J deactivate

L load

LR loadReversal

P authReversal

R credit

RR refundReversal

S echeckSale

T echeckCredit

UR unloadReversal

V void

W depositReversal

X echeckVoid

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

633
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.286 origCnpTxnId

The origCnpTxnId element is an optional child of the queryTransaction element and defines the
value of the cnpTxnId element assigned to the original transaction and returned in the response
message. You must include either the origId or the origCnpTxnId element or the system rejects the
query with a response Code of 154. Also, if you set the showStatusOnly element to Y, you must
include the origCnpTxnId element or the system declines the query with a response code of 155 -
origCnpTxnId is required when showStatusOnly is used.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
queryTransaction

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

634
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.287 origId

The origId element is an optional child of the queryTransaction element and defines the id
attribute used in the original transaction. You must include either the origId or the origCnpTxnId
element or the system rejects the query with a response Code of 154.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
queryTransaction

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

635
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.288 originalAmount

The originalAmount element is a required child of several gift card reversal transactions, as well as
the giftCardCapture transaction, where it specifies the amount of the original gift card transaction. In
the case of the giftCardCapture transaction, this is the amount associated with the authorization.
In the cast of a reversal transaction, it is the amount from the transaction you want to reverse. For
example, for an loadReversal it specifies the amount from the load transaction.
Type = Integer; totalDigits = 6

Parent Elements:
activateReversal, deactivateReversal, depositReversal, giftCardAuthReversal,giftCardCapture,
loadReversal, refundReversal, unloadReversal

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

636
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.289 originalCard

The originalCard element is an optional child of the accountUpdateResponse element, which

contains child elements providing the original information for the submitted card.

Parent Elements:
accountUpdateResponse

Attributes:
None
Child Elements:
type, number, expDate

Example: originalCard Structure

<originalCard>
<type>Card Type</type>
<number>Old Account Number</number>
<expDate>Old Expiration Date</expDate>
</originalCard>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

637
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.290 originalCardInfo

The originalCardInfo element is an optional child of the accountUpdater element, which contains
child elements providing the original information for the submitted card.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
type, number, expDate

Example: originalCard Structure

<originalCardInfo>
<type>Card Type</type>
<number>Old Account Number</number>
<expDate>Old Expiration Date</expDate>
</originalCardInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

638
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.291 originalCardTokenInfo

The originalCardTokenInfo element is an optional child of the accountUpdater element, which

contains child elements providing the original information for the submitted token.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
cnpToken, type, expDate, bin

Example: originalCard Structure

<originalCardTokenInfo>
<cnpToken>Old Token</cnpToken>
<type>Card Type</type>
<expDate>Old Expiration Date</expDate>
<bin>Old Card BIN</bin>
</originalCardTokenInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

639
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.292 originalNetworkTransactionId

The originalNetworkTransactionId element is an optional child of the authorization,

captureGivenAuth, and sale transactions. It defines the networkTransactionId returned in the
response messages for Visa and Discover Auth/Sale transactions. You must include this element and the
original value returned for subsequent (after the initial) Visa or Discover recurring/installment payments.
Type = String; minLength = N/A; maxLength = 30

NOTE: In the initial transaction of the recurring/installment stream, you must set the
processingType element to either initialRecurring or initialInstallment, as applicable.
As of April 2018, if you fail to include this element/value for a recurring/installment Visa or Discover
transaction, the card network may reject the transaction.

Parent Elements:
authorization, captureGivenAuth, sale

Attributes:
None

Child Elements:
None

4.292.1 Stored Credentials - After the Initial Transaction

After the initial request, you must set the orderSource element to the correct value, (in some cases)
include the processingType element for card on file transactions, and include the value from the
networkTransactionId element of the initial response in a new element,
originalNetworkTransactionId. Use the following table as a guide to the required values.

Payment Type <orderSource> <processingType> <originalNetworkTransactionId>

Recurring recurring N/A

Installment installment N/A Value of <networkTransactionId>

element from initial response message.
COF (merchant ecommerce merchantInitiatedCOF
initiated)

COF (cardholder ecommerce cardholderInitiatedCOF N/A

initiated)
applepay
3dsAuthenticated
3dsAttempted

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

640
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.293 originalRefCode

The originalRefCode element is a required child of several gift card transactions, where it specifies
the value returned in the refCode element of the associated giftCardResponse element of the
response messages.
Type = String; minLength = N/A; maxLength = 6

Parent Elements:
activateReversal, deactivateReversal, depositReversal, giftCardAuthReversal, giftCardCapture,
loadReversal, refundReversal, unloadReversal,

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

641
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.294 originalSequenceNumber

The originalSequenceNumber element is a required child of several gift card reversal transactions,
where it specifies the value returned in the sequenceNumber element of the associated
giftCardResponse element of the response messages.
Type = String; totalDigits = 6; Allowed Characters: 0 - 9

Parent Elements:
activateReversal, deactivateReversal, depositReversal, giftCardAuthReversal, loadReversal,
refundReversal, unloadReversal,

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

642
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.295 originalSystemTraceId

The originalSystemTraceId element is a required child of several gift card reversal transactions,
where it specifies the value returned in the systemTraceId element of the associated
giftCardResponse element from the response messages of the transaction you wish to reverse. For
example, for a loadReversal transaction, you use the value returned in the loadResponse message.
Type = Integer; totalDigits = 6

Parent Elements:
activateReversal, deactivateReversal, depositReversal, giftCardAuthReversal, loadReversal,
refundReversal, unloadReversal

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

643
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.296 originalToken

The originalToken element is an optional child of the accountUpdateResponse element, which

contains child elements providing the original information for the submitted token.

Parent Elements:
accountUpdateResponse

Attributes:
None
Child Elements:
cnpToken or tokenUrl, type, number, expDate, bin

Example: originalTokenStructure
<originalToken>
<cnpToken>Old Token Number</cnpToken>
<expDate>Old Expiration Date</expDate>
<type>Card Type</type>
<bin>Card BIN</bin>
</originalToken>

Example: originalToken Structure (with tokenUrl)

<originalToken>
<tokenUrl>Old Token URL</tokenUrl>
<expDate>Old Expiration Date</expDate>
<type>Card Type</type>
<bin>Card BIN</bin>
</originalToken>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

644
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.297 originalTokenInfo

The originalTokenInfo element is an optional child of the accountUpdater element, which

contains child elements providing the original token information for the submitted account. The system
returns this information when processing a tokenized Direct Debit transactions and a change (NOC) is
found against the account.

Parent Elements:
accountUpdater

Attributes:
None
Child Elements:
accType, cnpToken, routingNum

Example: originalAccountInfo Structure

<originalTokenInfo>
<accType>Account Type</accType>
<cnpToken>Old Account Number</cnpToken>
<routingNum>Old Routing Number</routingNum>
</originalTokenInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

645
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.298 originalTransactionAmount

NOTE: Currently, Discover does not require the inclusion of this element.

The originalTransactionAmount element is an optional child of the authorization,

captureGivenAuth, and sale transactions. It defines the amount from the initial transaction in a
recurring/installment stream. You must include this element and the original amount in subsequent (after
the initial) recurring/installment payments, if the payment method is Discover. You must also include the
originalNetworkTransactionId element using the value from the networkTransactionId
element returned in the initial transaction of the stream.

NOTE: In the initial transaction of the recurring/installment stream, you must set the
processingType element to either initialRecurring or initialInstallment, as applicable.

Type = Integer; totalDigits = 12

Parent Elements:
authorization, captureGivenAuth, sale

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

646
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.299 originalTxnTime

The originalTxnTime element is a required child of several gift card transactions, which specifies the
date and time the original transaction was processed by Worldpay. The system returns this value in the
txnTime child of the giftCardResponse element. The format of the element is YYYY-MM-DDTHH:MM:SS.
For example, 2016-11-21T11:00:00.
Type = dateTime; minLength = N/A; maxLength = 20

Parent Elements:
activateReversal, deactivateReversal, depositReversal, giftCardAuthReversal, giftCardCapture,
loadReversal, refundReversal, unloadReversal

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

647
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.300 password

The password element is a required child of the authentication element. It is used in combination
with the user element to authenticate that the message is from a valid source.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
authentication

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

648
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.301 payerId

The payerId element is a required child of the paypal element for all cases except for an Online Credit
transaction, where you can choose between this element and the payerEmail element. This element
specifies the Payer Id returned from PayPal.

NOTE: The value of the <payerId> element must match the PAYERID value returned by the
GetExpressCheckout call operation to PayPal.

Type = String; minLength = 1; maxLength = 17

Parent Elements:
paypal

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

649
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.302 payFacCredit

The payFacCredit element is the parent element for the transaction type that a Payment Facilitator
uses to distribute funds to themselves (i.e., from the PayFac Settlement Account to the PayFac Operating
Account). If you use V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundingSubmerchantId, fundsTransferId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

650
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.303 payFacCreditResponse

The payFacCreditResponse element is the parent element for information returned to you in response
to a payFacCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

651
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.304 payFacDebit

The payFacDebit element is the parent element for the transaction type that a Payment Facilitator uses
to move funds from the PayFac Operating Account back to the PayFac Settlement Account. If you use
V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundingSubmerchantId, fundsTransferId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

652
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.305 payFacDebitResponse

The payFacDebitResponse element is the parent element for information returned to you in response
to a payFacDebit transaction.

Parent Elements:
batchRequest, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacDebit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

653
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.306 paymentAccountReferenceNumber

The paymentDataType element is an optional child of both the authorizationResponse and

saleResponse elements. The value, assigned by the card network, is a constant correlation value that
represents the cardholder account regardless of updated account numbers or reissued cards. Worldpay
always returns the value, when the applicable card network makes it available.
Type = String; minLength = N/A; maxLength = 50

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

654
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.307 paymentDataType

The paymentDataType element is an optional child of the applepayResponse element and specifies
data type of the payment data associated with an Apple Pay transaction.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
applepayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

655
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.308 paymentPurpose

The paymentPurpose element is an optional child of the idealResponse and giropayResponse

elements where it specifies information (equivalent of Bill Descriptor for a credit card transaction) that
appears on the consumer bank statement along with a reference string representing the transaction. The
value has two components. The first part is a reference number assigned to the transaction. The second
part is a default merchant descriptor established during implementation.

NOTE: Although included in the schema, this API no longer supports the iDeal alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

Type = String; minLength = N/A; maxLength = 256

Parent Elements:
idealResponse, giropayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

656
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.309 payoutOrgCredit

The payoutOrgCredit element is the parent element for the transaction type that a direct merchant
uses to distribute funds to themselves (i.e., from the Settlement Account to the Operating Account). You
can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundingCustomerId, fundsTransferId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

657
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.310 payoutOrgCerditResponse

The payoutOrgCreditResponse element is the parent element for information returned to you in
response to a payoutOrgCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payoutOrgCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payoutOrgCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
payoutOrgCredit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

658
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.311 payoutOrgDebit

The payoutOrgDebit element is the parent element for the transaction type that a direct merchant uses
to move funds from the Operating Account to the Settlement Account. You can submit this transaction
type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundingCustomerId, fundsTransferId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

659
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.312 payoutOrgDebitResponse

The payoutOrgDebitResponse element is the parent element for information returned to you in
response to a payoutOrgDebit transaction.

Parent Elements:
batchRequest, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payoutOrgDebit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payoutOrgDebit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
payoutOrgDebit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

660
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.313 paypage

The paypage element defines eProtect account information. It replaces the card or token elements in
transactions using the eProtect feature of the Vault solution. When you submit the paypage element in a
request, response messages will include token information.

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale, updateSubscription, fastAccessFunding

Attributes:
None

Child Elements:
Required: paypageRegistrationId
Optional: expDate, cardValidationNum, type

NOTE: Although the schema defines the expDate element as an optional child of the paypage
element, you must submit a value for card-not-present transactions.

Example: Example: paypage Structure

<paypage>
<paypageRegistrationId>Registration ID from eProtect</paypageRegistrationId>
<expDate>Expiration Date</expDate>
<cardValidationNum>Card Validation Number</cardValidationNum>
<type>Method of Payment</type>
</paypage>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

661
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.314 paypageRegistrationId

The paypageRegistrationId element is a required child of the paypage element, and specifies the
Registration ID generated by eProtect. You can also use it in a Register Token Request to obtain a token
based on eProtect activity prior to submitting an Authorization or Sale transaction.
Type = String; minLength = N/A; maxLength = 512

Parent Elements:
paypage, registerTokenRequest

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

662
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.315 paypal

The paypal element defines paypal account information. It replaces the card or token elements in
transactions using PayPal as a payment method.

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
Required: payerId, transactionId
Optional: token

Example: paypal Structure

<paypal>
<payerId>PayPal Customer Identifier</payerId>
<token>Token Value Returned</token>
<transactionId>PayPal Transaction ID</transactionId>
</paypal>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

663
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.316 payPalNotes

The payPalNotes element is an optional child of multiple transaction types. You use this field to record
additional information about the PayPal transaction.
Type = String; Type = String; minLength = N/A; maxLength = 255

Parent Elements:
authReversal, capture, credit, sale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

664
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.317 payPalOrderComplete

The payPalOrderComplete element is an optional child of both the capture and sale elements, but is
required to close a PayPal order. Set the value to true to close the order, when you have fulfilled the
order and do not need to send any further auths or deposits against it. Set the value to false to keep the
order open for additional auths or deposits.
Type = Boolean; Valid values = true or false

Parent Elements:
capture, sale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

665
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.318 phone

The phone element has two different uses in cnpAPI depending upon the parent element. When used as
a child of either the billToAddress or shipToAddress elements, it defines the customers phone
number. When used as a child of the customBilling element, it defines the phone number of the
merchant.

4.318.0.1 phone as a child of billToAddress and shipToAddress

The phone element defines the customer’s phone number in both the billToAddress and
shipToAddress elements.

NOTE: When submitting an eCheck Verification, the string can only contain numbers (0 through 9).
Letters and special characters are not allowed.

Type = String; minLength = N/A; maxLength = 20

Parent Elements:
billToAddress, shipFromPostalCode

Attributes:
None
Child Elements:
None

4.318.0.2 phone as a child of customBilling

The phone element defines the merchant’s phone number. The string can only contain numbers (0
through 9). Letters and special characters are not allowed.
Type = String; minLength = N/A; maxLength = 13

Parent Elements:
customBilling

Attributes:
None
Child Elements: None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

666
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.319 physicalCheckCredit

The physicalCheckCredit element is the parent element for the transaction type that a Payment
Facilitator uses to distribute funds to a third party who issues physical checks on the Payment Facilitators
behalf. (i.e., from the PayFac Settlement Account to the Third Party Account). If you use V11.3 or above,
you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundsTransferId, and choice of fundingSubmerchantId or fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

667
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.320 physicalCheckCreditResponse

The physicalCheckCreditResponse element is the parent element for information returned to you in
response to a physicalCheckCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
physicalCheckCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
physicalCheckCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
physicalCheckCredit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

668
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.321 physicalCheckDebit

The physicalCheckDebit element is the parent element for the transaction type that a Payment
Facilitator uses to move funds from a third party who issues physical checks on the Payment Facilitator’s
behalf. (i.e., from the Third Party Account to the PayFac Settlement Account). If you use V11.3 or above,
you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: amount, fundsTransferId, and choice of fundingSubmerchantId or fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

669
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.322 physicalCheckDebitResponse

The physicalCheckDebitResponse element is the parent element for information returned to you in
response to a physicalCheckDebit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
physicalCheckDebit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
physicalCheckDebit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
physicalCheckDebit transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

670
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.323 pin

The pin element is an optional child of the several transaction types, as well as the card element. It only
applies to transactions involving closed-loop Gift Cards and defines the pin number associated with the
Gift Card.
Type = String; minLength = 4; maxLength = 12

Parent Elements:
capture, card, credit, virtualGiftCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

671
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.324 pinlessDebitRequest

The pinlessDebitRequest element is an optional child of the sale transaction and contains child
elements used to the control the routing behavior of Prime PINless Routing. The use of this element
applies only to merchants using the Prime - PINless Debit Routing service.

Parent Elements:
sale, authorization

NOTE: This element is not yet available for use in an Authorization transaction. Please consult your
Worldpay Relationship Manager for additional information.

Attributes:
None
Child Elements:
routingPreference, preferredDebitNetworks

Example: pinlessDebitRequest Structure

<pinlessDebitRequest>
<routingPreference>Routing Preference Enum Value</routingPreference>
<preferredDebitNetworks>
<debitNetworkName>Pulse</debitNetworkName>
<debitNetworkName>Star West</debitNetworkName>
.
.
.
<debitNetworkName>NYCE</debitNetworkName>
<debitNetworkName>Shazam</debitNetworkName>
</preferredDebitNetworks>
</pinlessDebitRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

672
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.325 pinlessDebitResponse

The pinlessDebitResponse element contains a child element used to specify the Debit Network used
for the transaction. This element appears only if you use the Worldpay Prime PINless Debit service and
Worldpay routed the transaction through a Debit Network for approval.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None
Child Elements:
networkName

Example: pinlessDebitResponse Structure

<pinlessDebitResponse>
<networkName>Debit Network Name</networkName>
</pinlessDebitResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

673
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.326 planCode

The planCode element is the identifier of a defined recurring payment plan. You use it to specify the
payment plan when submitting a recurring transaction to the Recurring Engine. For example, there could
be a define plan called Monthly that instructs the Recurring Engine to bill the consumer the same amount
every month for the number of months defined by the numberOfPayments element. This element is a
required child of the subscription element.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
subscription, updateSubscription, createPlan, updatePlan, updatePlanResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

674
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.327 pos

The pos element contains child elements used to specify information required when submitting
authorization, captureGivenAuth, credit, forceCapture, and sale transactions from point of
sale terminals.

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale

Attributes:
None
Child Elements:
capability, entryMode, cardholderId, terminalId, catLevel

Example: pos Structure

<pos>
<capability>Capabilty Enumeration</capability>
<entryMode>Entry Mode Enumeration</entryMode>
<cardholderId>Cardholder ID Enumeration</cardholderId>
<terminalId>1234567890</terminalId>
<catLevel>Capabilty of CAT Terminal</catLevel>
</pos>

NOTE: For CAT (Cardholder Activated Terminal) transactions, the capability element must be
set to magstripe, the cardholderId element must be set to nopin, and the catLevel element
must be set to self service.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

675
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.328 postDate

The postDate element defines the date the transaction was posted. The format is YYYY-MM-DD. It
occurs only in response to Online transactions.

NOTE: Although the schema defines this element as optional in most response messages, the
system returns it in the response for all Online transactions.

Type = Date; minLength = N/A; maxLength = 10

Parent Elements:
activateResponse, activateReversalResponse, authorizationResponse, authReversalResponse,
captureResponse, captureGivenAuthResponse, creditResponse, customerCreditResponse,
customerDebitResponse, deactivateResponse, deactivateReversalResponse, depositReversalResponse,
echeckCreditResponse, echeckSalesResponse, echeckVerificationResponse, forceCaptureResponse,
loadResponse, loadReversalResponse, refundReversalResponse, saleResponse, unloadResponse,
unloadReversalResponse, voidResponse, fastAccessFundingResponse, payFacCreditResponse,
payFacDebitResponse, physicalCheckCreditResponse, physicalCheckDebitResponse,
reserveCreditResponse, reserveDebitResponse, submerchantCreditResponse,
submerchantDebitResponse, vendorCreditResponse, vendorDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

676
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.329 postDay

The postDay element is an optional child of the accountUpdateFileRequestData element that

defines the date you submitted the Account Updater request. The format is YYYY-MM-DD.

NOTE: This is also the same date that the system created the Account Updater acknowledgment
file.

Type = Date; minLength = N/A; maxLength = 10

Parent Elements:
accountUpdateFileRequestData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

677
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.330 preferredDebitNetworks

The preferredDebitNetworks element is an optional child of the pinlessDebitRequest element

and contains a repeatable child element (up to 12 times) that allows you to specify the preferred debit
network or networks for processing this transaction. The use of this element applies only to merchants
using the Prime - PINless Debit Routing service.

Parent Elements: (optional for all)

pinlessDebitRequest

Attributes:
None
Child Elements:
debitNetworkName

Example: preferredDebitNetworks Structure

<preferredDebitNetworks>
<debitNetworkName>Pulse</debitNetworkName>
<debitNetworkName>Star West</debitNetworkName>
.
.
.
<debitNetworkName>NYCE</debitNetworkName>
<debitNetworkName>Shazam</debitNetworkName>
</preferredDebitNetworks>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

678
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.331 preferredLanguage

NOTE: Although included in the schema, this API no longer supports the SEPA, iDEAL, Giropay,
and SOFORT alternate payment methods. Please consult your Worldpay Relationship Manager for
additional information about alternate payment method support.

The preferredLanguage element is an optional child of the sepaDirectDebit element. This defines
the language in which the merchant prefers the mandate to appear. While the merchant could be able to
select any language, the mandate may not be available in the selected language. If the selected language
is not available, the mandate appears in English. If you do not include this element, the preferred
language defaults to the language indicated by the country of the IBAN, unless it is not available, in which
case the language defaults to English.
Type = String (Enum); minLength = N/A; maxLength = 3

NOTE: The enumerations for this element are listed under <countryTypeEnum> in the cnpAPI
Common XSD. The country names corresponding to the abbreviations can be found in the ISO
3166-1 standard.
All Country Codes are 2-character except for the United States, which accepts both US and USA.

Parent Elements:
sepaDirectDebit, ideal, giropay

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

679
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.332 prepaid

The prepaid element is an optional child of the filtering element. How you choose to implement the
Prepaid Filtering feature determines the use of the prepaid element. If your configuration filters all
prepaid card transactions, you can disable the feature on selected transactions by including the prepaid
element with a setting of false. If your configuration filters prepaid card transactions on a per transaction
basis, you enable the filtering on a selected transaction by including the prepaid element with a setting
of true.
Type = Boolean; Valid Values = true or false

Parent Elements:
filtering

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

680
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.333 prepaidCardType

The prepaidCardType element is an optional child of the enhancedAuthResponse element, which

specifies the type of prepaid card submitted in the Authorization or Sale transaction. For example, a few
of the possible values are: GIFT, PAYROLL, and GENERAL_PREPAID
Type = String; minLength = N/A; maxLength = 50

Parent Elements:
fundingSource

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

681
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.334 processingInstructions

The processingInstructions element contains a child element that allows you to specify whether or
not the system performs velocity checking on the transaction.

Parent Elements: (optional for all)

authorization, capture, captureGivenAuth, credit, forceCapture, sale, void

Attributes:
None
Child Elements:
bypassVelocityCheck

NOTE: Please consult your Relationship Manager for additional information concerning Velocity
Checking.

Example: processingInstructions Structure

<processingInstructions>
<bypassVelocityCheck>true or false</bypassVelocityCheck>
</processingInstructions>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

682
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.335 processingType

The processingType element is an optional child of several transaction types. You use this element to
define a Visa transaction used to fund a host-based prepaid product, a brokerage account, or an escrow
account (accountFunding enum value). You also use it to define the initial transaction in a recurring or
installment stream, or the initial, merchant initiated, or cardholder initiated Card on file transaction. For
these cases, you must store the value of the networkTransactionId element returned in the response
message. You use that value to populate the originalNetworkTransactionId element in
subsequent recurring/installment or CoF transactions. This allows the networks to tie subsequent
transactions back to the original approval.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
authorization, captureGivenAuth, forceCapture, sale

Attributes:
None
Child Elements:
None

Enumerations:

Enum Description

accountFunding Use this value to define a Visa transaction is intended to fund a host-based
prepaid product, a brokerage account, or an escrow account.
initialRecurring Use this value to specify the first in a series of recurring payment
transactions.
initialInstallment Use this value to specify the first in a series of installment payment
transactions.
initialCOF Use this value to specify an initial Card on File transaction.
merchantInitiatedCOF Use this value to specify a merchant initiated Card on File transaction after
the initial CoF transaction.
cardholderInitiatedCOF Use this value to specify a cardholder initiated Card on File transaction after
the initial CoF transaction.

4.335.1 Stored Credentials - After the Initial Transaction

After the initial request, you must set the orderSource element to the correct value, (in some cases)
include the processingType element for card on file transactions, and include the value from the
networkTransactionId element of the initial response in a new element,
originalNetworkTransactionId. Use the following table as a guide to the required values.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

683
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Payment Type <orderSource> <processingType> <originalNetworkTransactionId>

Recurring recurring N/A

Installment installment N/A Value of <networkTransactionId>

element from initial response message.
COF (merchant ecommerce merchantInitiatedCOF
initiated)

COF (cardholder ecommerce cardholderInitiatedCOF N/A

initiated)
applepay
3dsAuthenticated
3dsAttempted

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

684
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.336 productCode

The productCode element is an optional child of the lineItemData element, which specifies the
product code of the purchased item. This value is a merchant defined description code of the
product/service. This could be an inventory number, UPC, catalog number, or some other value that the
merchant uses to define the specific product. Although an optional element, it is required by Visa and
Mastercard when specifying line item data.
Type = String; minLength = 1; maxLength = 12

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

685
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.337 programCode

The programCode element is an optional child of the lodgingInfo element and defines whether the
associated charges are for LODGING, NOSHOW or ADVANCEDDEPOSIT.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
lodgingInfo

Attributes:
None
Child Elements:
None

Enumerations:

Enum Description

LODGING (Default) Submitted charges are for lodging.

NOSHOW Submitted charges are for the failure of the guest(s) to check in for reserved a room.

ADVANCED Submitted charges are for an Advanced Deposit to reserve one or more rooms.
DEPOSIT

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

686
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.338 propertyLocalPhone

The propertyLocalPhone element is an optional child of the lodgingInfo element and defines local
phone number of the facility. For a Mastercard transaction, you must include a value for this element to
achieve better interchange rates.
Type = String; minLength = N/A; maxLength = 17

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

687
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.339 publicKeyHash

The publicKeyHash element is a required child of the header element and provides the BASE64
Encoded string that is a hash of the merchant’s certificate public key bytes associated with the Apple Pay
transaction.
Type = Base 64 Encoded String; minLength = N/A; maxLength = 200

Parent Elements:
header

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

688
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.340 quantity

The quantity element is an optional child of the lineItemData element, which specifies the number
of items purchased. Although an optional element, it is required by Visa and Mastercard when specifying
line item data. The value must be greater than zero, but no more than 12 digits not including the decimal
point.

NOTE: If you accidentally omit the quantity element, our system will submit the transaction using
a default value of 1.

Type = Decimal; minInclusive = 0; totalDigits = 12

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

689
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.341 queryTransaction

The queryTransaction element is the parent element for Query transactions. You use this transaction
type to determine the status of a previously submitted transaction. You can submit this element only as an
Online transaction.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Optional: origId, origActionType, origCnpTxnId, showStatusOnly

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

690
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.342 queryTransactionResponse

The queryTransactionResponse element is the parent element for the response to

queryTransaction requests.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
capture transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
capture transaction.
minLength = 1 maxLength = 25

Child Elements:
All Required: response, responseTime, message, matchCount, results_Max10
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

691
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.343 queryTransactionUnavailableResponse

The queryTransactionUnavailableResponse element is an optional child of the results_Max10

element. If the query results is a response code of 152 - Transaction found, but response not yet
available, the results_Max10 element will contain at least one
queryTransactionUnavailableResponse child (see example results_Max10 Element for 152
Response Code).

Parent Elements:
results_Max10

Attributes:
None
Child Elements:
All Required: cnpTxnId, response, message
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

692
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.344 recurringRequest

The recurringRequest element is the parent of several child element that define the number of
payments and plan type of recurring transaction to be handled by the Recurring Engine. It is an optional
child of the Authorization and Sale transactions.

Parent Elements:
authorization, sale

Attributes:
None

Child Elements:
subscription

Example: recurringRequest Structure

<recurringRequest>
<subscription>
<planCode>Plan Reference Code</planCode>
<numberOfPayments>1 to 99</numberOfRemianingPayments>
<startDate>Start Date of Recurring Cycle</startDate>
<amount>Amount of Recurring Payment</amount>
</subscription>
</recurringRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

693
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.345 recurringResponse

The recuringResponse element is the parent element for the subscriptionId, responseCode,
responseMessage, and recurringTxnId elements associated with a requested recurring payment. The
system returns this element only when the sale transaction includes a recurringRequest element.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None

Child Elements:
subscriptionId, responseCode, responseMessage, recurringTxnId

Example: recurringResponse Structure

<recurringResponse>
<subscriptionId>1234567890</subscriptionId>
<responseCode>Response Code</responseCode>
<responseMessage>Response Message</responseMessage>
</recurringResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

694
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.346 recurringTxnId

The recurringTxnId element is an optional child of the recurringResponse element used to

identify the record of recurring, scheduled transactions.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
recurringResponse, cnpInternalRecurringRequest

NOTE: Although the element is an optional child of the recurringResponse element, it will never
be returned in the response to a merchant initiated transaction.

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

695
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.347 recycleAdvice

NOTE: The recycling Advice feature is no longer supported.

The recyclingAdvice element contains a two child elements that either specifies the date and time (in
GMT) recommended for the next recycle of the declined Authorization/Sale transaction or indicates that
there is no additional recycling advice. The two children are mutually exclusive.

Parent Elements: (optional for all)

recyclingResponse

Attributes:
None
Child Elements:
nextRecycleTime, recycleAdviceEnd

Example: recycleAdvice Structure - with recommended Date:Time

<recycleAdvice>
<nextRecycleTime>2016-11-15T12:00:00</nextRecycleTime>
</recycleAdvice>

Example: recycleAdvice Structure - with end message

<recycleAdvice>
<recycleAdviceEnd>End of Advice</recycleAdviceEnd>
</recycleAdvice>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

696
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.348 recycleAdviceEnd

NOTE: The recycling Advice feature is no longer supported.

The recycleAdviceEnd element is an optional child of the recycleAdvice element and signifies that
no further recycling recommendations are available.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
recycleAdvice

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

697
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.349 recycleBy

The recycleBy element is an optional child of the recyclingRequest element and determines the
use of the Recycling Engine. The default setting is Cnp, so omitting this element is the same as
submitting a value of Cnp.

NOTE: Also, if your Merchant Profile includes a preset percentage split of transactions between
merchant and Worldpay controlled, then settings of Merchant and Cnp are ignored; you can still
use a setting of None to exclude the transaction.
Also, although the default setting is normally Cnp, it can be altered in your merchant profile to a
setting of Merchant.

Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
recyclingRequest

Attributes:
None
Child Elements:
None

Enumerations:

Enum Description

Merchant This setting indicates that the merchant controls the recycling of the transaction. For A/B
comparison testing, transactions using this setting will be counted as merchant controlled.
After setting this value in the initial transaction, subsequent transactions should have
same value. Any different value will be ignored.

Cnp This setting indicates either that the Recycling Engine controls the recycling of the
transaction. For A/B comparison testing, transactions using this setting will be counted as
Worldpay controlled.
After setting this value in the initial transaction, subsequent transactions should have
same value. Any different value will be ignored.

None For A/B comparison testing, transactions using this setting are excluded from all counts.
These transactions will not be counted as either merchant or Worldpay controlled.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

698
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.350 recycleEngineActive

The recycleEngineActive element is an optional child of the recycling element that indicates
whether or not the engine is recycling the declined transaction. This element is returned only if you are
using the Recycling Engine.
Type = Boolean; Valid values = true or false

Parent Elements:
recyclingResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

699
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.351 recycleId

The recycleId element is an optional child of the recyclingRequest element. Merchants can use
this identifier as part of the transaction signature used to track the recycling of a transaction. This element
is an alternative to using the orderId element as part of the transaction signature.
Type = String; minLength = N/A; maxLength = 25

Parent Elements:
recyclingRequest

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

700
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.352 recyclingResponse

The recyclingResponse element has two uses in the cnpAPI depending upon the parent. When used
as a child of either the authorizationResponse or saleResponse elements, the recycling
element contains a child element that specifies whether or not the engine is recycling the declined
transaction.
When used as a child of the voidResponse, the recyclingResponse element contains a child
providing the Transaction Id of the Credit transaction issued. This occurs only if a Void transaction is used
to halt the recycling of a transaction by the recycling engine and the transaction has already been
approved and captured (see Using Void to Halt Recycling Engine on page 78).

4.352.1 recyclingResponse Element as a Child of authorizationResponse

or saleResponse
The recyclingResponse element contains child elements indicating that the Recycling Engine is
active.

Parent Elements:
authorizationResponse, saleResponse

Attributes:
None
Child Elements:
recycleAdvice, recycleEngineActive

NOTE: The recycling Advice feature is no longer supported.

Example: recycling Structure - with engine active flag

<recyclingResponse>
<recycleEngineActive>true or false</recycleEngineActive>
</recyclingResponse>

4.352.2 recyclingResponse Element as a Child of voidResponse

The recyclingResponse element in an optional child of the voidResponse element and contains a
child providing the Transaction Id of the Credit transaction issued. This element is present in the Void
response only under the following circumstances (see Using Void to Halt Recycling Engine on page 78):
• You submitted a Void transaction to halt the recycling of a declined Sale transaction by the
Recovery/Recycling Engine.
• The Sale transaction has already been approved and captured.
• Your Recovery/Recycling Engine configuration enables automatic refunds.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

701
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

• The system has successfully submitted a Credit transaction on your behalf.

Parent Elements:
voidResponse

Attributes:
None
Child Elements:
creditCnpTxnId

Example: recycling Structure - child of voidResponse

<recyclingResponse>
<creditcnpTxnId>1234567890123456789</creditcnpTxnId>
</recyclingResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

702
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.353 recyclingRequest

The recyclingrequest element is an optional child of the authorization and sale transactions,
which contains a child element that specifies who is responsible for recycling the transaction. It also
contains an optional element for an identifier assigned by the merchant to track the recycling of the
transaction. This element only applies to merchants using the Recycling Engine.

Parent Elements:
authorization, sale

Attributes:
None
Child Elements:
recycleBy, recycleId

Example: recyclingRequest Structure

<recyclingRequest>
<recycleBy>Merchant or Cnp or None</recycleBy>
<recycleId>abcdef1234567890</recycleId>
</recyclingRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

703
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.354 redirectToken

NOTE: Although included in the schema, this API no longer supports the SEPA, iDEAL, and
Giropay alternate payment methods. Please consult your Worldpay Relationship Manager for
additional information about SEPA support.

The redirectToken element is an optional child of the sepaDirectDebitResponse,

idealResponse, and giropayResponse elements. It allows you to verify that the consumer accepted
the Mandate by comparing it to the token_value parameter returned in the URL upon redirect from the
Mandate site.
Type = String; minLength = N/A; maxLength = 128

Parent Elements:
sepaDirectDebitResponse, idealResponse, giropayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

704
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.355 redirectUrl

NOTE: Although included in the schema, this API no longer supports the SEPA, iDEAL, and
Giropay alternate payment methods. Please consult your Worldpay Relationship Manager for
additional information about SEPA support.

The redirectUrl element is an optional child of the sepaDirectDebit element and defines the URL
that hosts the mandate, when Worldpay supplies the mandate. If you supply the mandate
(<mandateProvider>Merchant</mandateProvider>), this element will not appear in the response.
Type = String; minLength = N/A; maxLength = 256

Parent Elements:
sepaDirectDebitResponse, idealResponse, giropayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

705
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.356 refCode

The refCode element is an optional child of the giftCardResponse element, where it specifies the
authorization code of the gift card transaction.
Type = String; minLength = N/A; maxLength = 6

Parent Elements:
giftCardResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

706
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.357 refundReversal

The refundReversal element is the parent element for a Gift Card specific transaction type that
reverses the a refund associated with a Gift Card.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

707
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.358 refundReversalResponse

The refundReversalResponse element is the parent element for information returned to you in
response to an refundReversal transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Refund Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Refund Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Refund Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, giftCardResponse
Optional: postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

708
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.359 registerTokenRequest

The registerTokenRequest element is the parent element for the Register Token transaction. You
use this transaction type when you wish to submit an account number for tokenization, but there is no
associated payment transaction.
You can use this element in either Online or Batch transactions.

NOTE: When submitting registerTokenRequest elements in a batchRequest, you must also

include a numTokenRegistrations= attribute in the batchRequest element.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and mirrored

back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute defining the merchant sub-group in the
user interface where this transaction displays. Also see
Coding for Report Groups on page 10 for information.
minLength = 1 maxLength = 25

Child Elements:
Required: either accountNumber, echeckForToken, mpos, paypageRegistrationId,
encryptedAccountNumber, or applepay
Optional: orderId, cardValidationNum, encryptedCardValidationNum, encryptionKeyId

NOTE: The use of the cardValidationNum element in the registertokenRequest only

applies when you submit an accountNumber element.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

709
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.360 registerTokenResponse

The registerTokenResponse element is the parent element for the response to

registerTokenRequest transactions. You receive this transaction type in response to the submission
of an account number for tokenization in a registerTokenRequest transaction.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
registerTokenRequest transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
registerTokenRequest transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
registerTokenRequest transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, message, responseTime
Optional: eCheckAccountSuffix, cnpToken, bin, type, applepayResponse, androidpayResponse,
accountRangeId, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

710
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.361 reloadable

The reloadable element is an optional child of the fundingSource element and defines whether the
prepaid card is reloadable.

NOTE: The system never returns this element for American Express card transactions.

Type = String (Enum); Enumerations = YES, NO, or UNKNOWN

Parent Elements:
fundingSource

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

711
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.362 reserveCredit

The reserveCredit element is the parent element for the transaction type that a Payment Facilitator
uses to move funds from the PayFac Settlement Account to the PayFac Reserve Account. If you use
V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: amount, fundsTransferId, and choice of fundingSubmerchantId or fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

712
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.363 reserveCreditResponse

The reserveCreditResponse element is the parent element for information returned to you in
response to a reserveCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
reserveCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

713
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.364 reserveDebit

The reserveDebit element is the parent element for the transaction type that a Payment Facilitator
uses to move funds from the PayFac Reserve Account to the PayFac Settlement Account. If you use
V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest
Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: amount, fundsTransferId, and choice of fundingSubmerchantId or fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

714
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.365 reserveDebitResponse

The reserveDebitResponse element is the parent element for information returned to you in response
to a reserveDebit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
reserveDebit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

715
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.366 residenceStatus

The residenceStatus element is an optional child of the customerInfo element and defines the type
of domicile in which the customer resides. It is used in combination with several other elements to provide
required information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = String (Enum); Enumerations = Own, Rent, or Other

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

716
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.367 response

The response element contains a three digit numeric code which specifies either that the transaction is
approved (000 code) or declined. The message element provides a brief definition of the response code.
For a complete list of response codes and associated messages, please refer to Payment Transaction
Response Codes on page 832.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
activateResponse, activateReversalResponse, authorizationResponse, authReversalResponse,
captureResponse, captureGivenAuthResponse, creditResponse, customerCreditResponse,
customerDebitResponse, deactivateResponse, deactivateReversalResponse, depositReversalResponse,
echeckCreditResponse, echeckPreNoteCreditResponse, echeckPreNoteSaleResponse,
echeckRedepositResponse, echeckSalesResponse, echeckVerificationResponse, echeckVoidResponse,
forceCaptureResponse, fraudCheckResponse, loadResponse, loadReversalResponse,
queryTransactionResponse, queryTransactionUnavailableResponse, registerTokenResponse,
refundReversalResponse, saleResponse, voidResponse, cancelSubscriptionResponse,
unloadResponse, updatePlanResponse, updateSubscriptionResponse, unloadReversalResponse,
payFacCreditResponse, payFacDebitResponse, physicalCheckCreditResponse,
physicalCheckDebitResponse, submerchantCreditResponse, reserveCreditResponse,
reserveDebitResponse, submerchantDebitResponse, vendorCreditResponse, vendorDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

717
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.368 responseCode

The responseCode element contains a three digit numeric code which along with the
responseMessage element specifies either acceptance by the Recurring Engine or the reason the
recurring Engine was unable to schedule subsequent payments.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
recurringResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

718
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.369 responseMessage

The responseMessage element contains a brief definition of the responseCode returned for the
recurring transaction.
Type = String; minLength = N/A; maxLength = 512

Parent Elements:
recurringResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

719
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.370 responseTime

The responseTime element provides a date/time stamp of the response. The format of the element is
YYYY-MM-DDTHH:MM:SS. For example, 2009-12-21T11:37:04.
Type = dateTime; minLength = N/A; maxLength = 19

Parent Elements:
activateResponse, activateReversalResponse, authorizationResponse, authReversalResponse,
captureResponse, captureGivenAuthResponse, creditResponse, customerCreditResponse,
customerDebitResponse, deactivateResponse, deactivateReversalResponse,
depositReversalResponse,echeckCreditResponse, echeckPreNoteCreditResponse,
echeckPreNoteSaleResponse, echeckRedepositResponse, echeckSalesResponse,
echeckVerificationResponse, echeckVoidResponse, forceCaptureResponse, fraudCheckResponse,
loadResponse, loadReversalResponse, queryTransactionResponse, registerTokenResponse,
refundReversalResponse, saleResponse, voidResponse, cancelSubscriptionResponse,
unloadResponse, unloadReversalResponse, updatePlanResponse, updateSubscriptionResponse,
payFacCreditResponse, payFacDebitResponse, physicalCheckCreditResponse,
physicalCheckDebitResponse, reserveCreditResponse, reserveDebitResponse,
submerchantCreditResponse, submerchantDebitResponse, vendorCreditResponse,
vendorDebitResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

720
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.371 results_Max10

The results_Max10 element is a required child of the queryTransactionResponse. Any original

transaction responses that match the criteria submitted in the queryTransaction appear as children of
this element in the response. The system can return a maximum of ten responses as children of the
results_Max10 element. The value for the matchCount element reflects the number of found
transactions.
If the system does not find any transactions matching the query criteria, the results_Max10 element will
be empty.
If the query results is a response code of 152 - Transaction found, but response not yet available, the
results_Max10 element will contain at least one queryTransactionUnavailableResponse child
and may contain other found responses.

Parent Elements:
queryTransactionResponse

Attributes:
None
Child Elements:
All Optional: activateResponse, activateReversalResponse, authorizationResponse, captureResponse,
creditResponse, deactivateResponse, depositReversalResponse, echeckCreditResponse,
echeckSalesResponse, loadResponse, loadReversalResponse, refundReversalResponse,
saleResponse, unloadResponse, unloadReversalResponse, voidResponse,
queryTransactionUnavailableResponse

Example: results_Max10 Element with One Found Transaction

<results_max10>
<authorizationResponse id="GiftCardAuth" reportGroup="Mer5PM1" customerId="1">
<cnpTxnId>82827170811986124</cnpTxnId>
<orderId>150330_GCAuth</orderId>
<response>000</response>
responseTime>2015-04-06T16:40:04</responseTime>
<postDate>2015-04-06</postDate>
<message>Approved</message>
<authCode>111115</authCode>
<fraudResult>
<avsResult>30</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
<giftCardResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

721
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<availableBalance>125</availableBalance>
</giftCardResponse>
</authorizationResponse>
</results_max10>

Example: results_Max10 Element with Multiple Found Transactions

<results_max10>
<authorizationResponse id="DupeId" reportGroup="Mer5PM1">
<cnpTxnId>82827170811986215</cnpTxnId>
<orderId>150331_DupeAuth2</orderId>
<response>000</response>
<responseTime>2015-04-06T16:40:12</responseTime>
<postDate>2015-04-06</postDate>
<message>Approved</message>
<authCode>055858</authCode>
<fraudResult>
<avsResult>32</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
</authorizationResponse>
<authorizationResponse id="DupeId" reportGroup="Mer5PM1">
<cnpTxnId>82827170811986207</cnpTxnId>
<orderId>150331_DupeAuth1</orderId>
<response>000</response>
<responseTime>2015-04-06T16:40:11</responseTime>
<postDate>2015-04-06</postDate>
<message>Approved</message>
<authCode>111111</authCode>
<fraudResult>
<avsResult>00</avsResult>
<cardValidationResult>M</cardValidationResult>
</fraudResult>
</authorizationResponse>
</results_max10>

Example: results_Max10 Element for 152 Response Code

<results_max10>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

722
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<queryTransactionUnavailableResponse>
<cnpTxnId>82827170811986124</cnpTxnId>
<response>152</response>
<message>Original transaction found but response not yet available</message>
</queryTransactionUnavailableResponse>
</results_max10>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

723
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.372 RFRRequest

The RFRRequest element is an optional child of a cnpRequest element. You can use this type of
request in one of two ways.
• To request a session response from a previously processed cnpRequest, include the
cnpSessionId child. The resulting RFR response will duplicate the original session response
(Authorization, Credit, Capture, or Sale response) associated with the cnpSessionId. The session
ID returned in the response will be the session ID of the original session.
• To request an Account Updater completion response file, include the
accountUpdateFileRequestData element. If the completion file is ready, it is returned. If the
completion file is not ready, you receive an RFRResponse message with the response attribute set to
1 and the message attribute reading, “The account Update file is not ready yet. Please try again
later.”

Parent Elements:
cnpRequest

Attributes:
None
Child Elements: (Choice of)
cnpSessionId or accountUpdateFileRequestData

Example: RFRRequest Structure - Batch

<RFRRequest>
<cnpSessionId>Session ID</cnpSessionId>
</RFRRequest>

Example: RFRRequest Structure - Account Updater

<RFRRequest>
<accountUpdateFileRequestData>
<merchantId>Merchant ID</merchantId>
<postDay>Post Date</postDay>
</accountUpdateFileRequestData>
</RFRRequest>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

724
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.373 RFRResponse

The RFRResponse element is an optional child of a cnpResponse element returned in response to a

RFRRequest.

Parent Elements:
cnpResponse

Attributes:

Attribute Name Type Required? Description

response String Yes The RFR Response Code indicating the result of the
RFR request.
minLength = N/A maxLength = 3

message String Yes A brief definition of the response code returned for this
transaction.
minLength = N/A maxLength = 512

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

725
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.374 roomRate

The roomRate element is an optional child of the lodgingInfo element and defines per day room
charges exclusive of any taxes and fees. Supply the value in cents without a decimal point. For example,
a value of 1995 signifies $19.95.
Type = Integer; totalDigits = 12

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

726
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.375 roomTax

The roomTax element is an optional child of the lodgingInfo element and defines per day room tax.
Supply the value in cents without a decimal point. For example, a value of 1995 signifies $19.95.
Type = Integer; totalDigits = 12

Parent Elements:
lodgingInfo

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

727
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.376 routingNum

The routingNum element is a required child of the echeck, originalAccountInfo, and

newAccountInfo elements defining the routing number of the Direct Debit account.
Type = String; minLength = 8; maxLength = 9

IMPORTANT: Be sure to submit the exact value without stripping or padding.

Parent Elements:
echeck, newAccountInfo, originalAccountInfo, newTokenInfo, originalTokenInfo, accountInfo

Attributes:
None
Child Elements:
None

NOTE: If you submit an invalid routing number, we return the XML Response Code 900 - Invalid
Bank Routing Number.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

728
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.377 routingPreference

The routingPreference element is an optional child of the pinlessDebitRequest element and

defines the merchant preference for the routing of this transaction. The use of this element applies only to
merchants using the Prime - PINless Debit Routing service.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
pinlessDebitRequest

Attributes:
None
Child Elements:
None

Enumerations:

Enumeration Description

pinlessDebitOnly Route the transaction only through the

PINless Debit networks.

signatureOnly Route the transaction only through the

signature networks.

regular Use regular routing scenarios.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

729
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.378 RxAmount

The RxAmount element is an optional child of the healthcareAmounts element and defines the
healthcare amount used for the purchased medications. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
Optional: healthcareAmounts

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

730
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.379 sale

The sale element is the parent element for all Sale transactions. A Sale transaction is a combination
Authorization and Capture transaction. You can use this element in either Online or Batch transactions.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: orderId, amount, orderSource, (choice of) card, paypal, paypage, mpos, token, applepay, ideal,
sepaDirectDebit, giropay, or sofort

NOTE: The cardholderAuthentication child element is required only for 3-D Secure transactions.
The fraudCheck element has been deprecated; use the cardholderAuthentication element
instead.

Optional: customerInfo, billToAddress, shipToAddress, cardholderAuthentication, customBilling, taxType,

enhancedData, processingInstructions, pos, payPalNotes, payPalOrderComplete, allowPartialAuth,
healthcareIIAS, merchantData, recyclingRequest, fraudFilterOverride, secondaryAmount,
surchargeAmount, recurringRequest, cnpInternalRecurringRequest, debtRepayment,
advancedFraudChecks, wallet, processingType, filtering, originalNetworkTransactionId,
originalTransactionAmount, pinlessDebitRequest, lodgingInfo, skipRealtimeAU, merchantCategoryCode

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

731
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.380 saleResponse

The saleResponse element is the parent element for information returned in response to a Sale
transaction. It can be a child of either a cnpOnlineResponse element or a batchResponse element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute
Name Type Required? Description

id String Yes The response returns the same value submitted in the Sale
transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the Sale
transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the Sale
transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, orderId, response, responseTime, message
Optional: postDate, cardProductId (see Note below), authCode, authorizationResponseSubCode (see
Note below), approvedAmount, accountInformation, fraudResult, tokenResponse,
enhancedAuthResponse, accountUpdater, recyclingResponse, recurringResponse, giftCardResponse,
applepayResponse, cardSuffix, androidpayResponse, networkTransactionId,
paymentAccountReferenceNumber, location

NOTE: The postDate child element is returned only in responses to Online transactions.
The cardProductId element returns a raw code referencing the card type. Please consult your
Relationship Manager for additional information.
The authorizationResponseSubCode element is not used at this time.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

732
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.381 salesTax

The salesTax element defines the amount of sales tax included in the transaction amount. Although the
schema defines it as an optional child of the enhancedData element, it is required to receive the best
interchange rate for Level II and Level III corporate purchases. The decimal is implied. Example: 500 =
$5.00.

NOTE: For a non-taxable transaction, use 0 as the value. In this case you must also set the
taxExempt element to true.
If you provide detailTax data, the salesTax should be the sum of the detailTax.

Type = Integer; totalDigits = 8

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

733
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.382 secondaryAmount

The secondaryAmount element defines the principal portion of the total amount when a convenience
fee applied to the transaction by the merchant. for example, if the total charge is $105, with the principal
amount being $100 and the convenience fee being $5, you must use $100 as the value for the
secondaryAmount element. Supply the value in cents without a decimal point. For example, a value of
400 signifies $4.00.

NOTE: Worldpay supports convenience fees for Mastercard and Visa card brands only. Attempting
to use this element in a Discover or American Express transaction results in a decline with the
response code of 381 - This method of payment does not support secondary amount.

Type = Integer; totalDigits = 12

Parent Elements:
authorization, credit, captureGivenAuth, echeckCredit, echeckSale, forceCapture, sale

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

734
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.383 sepaDirectDebit

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The sepaDirectDebit element is a child of the sale transaction that, through its child elements,
defines information needed to process a SEPA Direct Debit transaction. At this time, you can use the
SEPA Direct Debit method of payment in Online transactions only.

Parent Elements:
sale

Attributes:
None

Child Elements:
Required: iban, mandateProvider, sequenceType
Optional: mandateReference, mandateURL, mandateSignatureDate, preferredLanguage

Example: sepaDirectDebit Structure

<sepaDirectDebit>
<mandateProvider>Merchant or Vantiv</mandateProvider>
<sequenceType>One Time or Type of Recurring</sequenceType>
<mandateReference>Ref to First Payment of Recurring Stream</mandateReference>
<mandateUrl>URL of Merchant Hosted Mandtae</mandateUrl>
<mandateSignatureDate>2016-06-12</mandateSignatureDate>
<iban>Consumer Account Number</iban>
<preferredLanguage>Country Code of Language</preferredLanguage>
</sepaDirectDebit>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

735
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.384 sepaDirectDebitResponse

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The sepaDirectDebitResponse element is a child of the saleResponse transaction when the

method of payment in the request is sepaDirectDebit. It contains child elements that you should store
for future use/reference.

Parent Elements:
saleResponse

Attributes:
None

Child Elements (all Optional):

mandateReference, redirectUrl, redirectToken

Example: sepaDirectDebitResponse Structure

<sepaDirectDebitResponse>
<redirectUrl>URL of Vantiv Supplied Mandate</redirectUrl>
<redirectToken>Map Mandate to cnpTxnId</redirectToken>
<mandateReference>Ref Number for Subsequent Payments</mandateReference>
</sepaDirectDebit>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

736
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.385 sequenceNumber

The sequenceNumber element is an optional child of the giftCardResponse element, which specifies
a Worldpay generated sequence number associated with the transaction in our systems. You should
retain this value for possible future use in gift card reversal transactions.
Type = String; totalDigits = 6; Allowed Characters: 0 - 9

Parent Elements:
giftCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

737
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.386 sequenceType

NOTE: Although included in the schema, this API no longer supports the SEPA alternate payment
method. Please consult your Worldpay Relationship Manager for additional information about SEPA
support.

The sequenceType element is a required child of the sepaDirectDebit element and defines the
purchase in terms of a one-time buy or a member of a recurring stream of debits. If the value of this
element is either SubsequentRecurring, or FinalRecurring, you must include the mandateReference
element in the request, specifying the value returned in the initial sepaDirectDebitResponse.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
sepaDirectDebit

Attributes:
None
Child Elements:
None

Enumerations:

Enumeration Description

OneTime The purchase is a one-time buy (i.e., not part

of a recurring stream).

FirstRecurring This purchase is the initial buy of a recurring

stream.

SubsequentRecurring This purchase is part of a recurring stream of

purchases, but not the first or last in the
stream.

FinalRecurring This purchase is the final buy of a recurring

stream.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

738
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.387 shipFromPostalCode

The shipFromPostalCode element defines the postal code from which the product ships in the
enhancedData element.
Type = String; minLength = N/A; maxLength = 20

NOTE: Although the schema specifies the maxLength of the <shipFromPostalCode> element as
20 characters, in practice you should never exceed 10 characters in your submissions.

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

739
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.388 shippingAmount

The shippingAmount element defines shipping cost for the order. Although the schema defines it as an
optional child of the enhancedData element, it is required by Visa for Level III interchange rates. The
decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

740
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.389 shipToAddress

The shipToAddress element contains several child elements that define the postal mailing address
(and telephone number) used for shipping purposes.

Parent Elements:
authorization, captureGivenAuth, fraudCheck, sale

Attributes:
None
Child Elements: (all Optional)
name, addressLine1, addressLine2, addressLine3, city, state, zip, country, email, phone

Example: shipToAddress Structure

<shipToAddress>
<name>Customer’s Full Name</name>
<addressLine1>Address Line 1</addressLine1>
<addressLine2>Address Line 2</addressLine2>
<addressLine3>Address Line 3</addressLine3>
<city>City</city>
<state>State Abbreviation</state>
<zip>ZIP Code</zip>
<country>Country Code</country>
<email>Email Address</email>
<phone>Telephone Number</phone>
</shipToAddress>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

741
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.390 showStatusOnly

The shoeStatusOnly element is an optional child of the queryTransaction element and specifies
whether or not the query returns only the status of the previously submitted transaction. If you set the
element to Y, you must also include the origCnpTxnId element or the system declines the query with a
response code of 155 - origCnpTxnId is required when showStatusOnly is used
Type = Boolean; Valid values = Y or N

Parent Elements:
queryTransaction

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

742
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.391 signature

The signature element is a required child of the applepay element. It is the BASE64 encoded string
signature of the payment and header data from the PKPaymentToken.
Type = String; minLength = N/A; maxLength = 10000

Parent Elements:
applepay

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

743
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.392 skipRealtimeAU

The skipRealtimeAU element is an optional child of both the authorization and sale
transactions. Setting this element to true allows you to skip any real-time account updates on the
submitted transaction.
Type = Boolean; Valid values = true or false (default)

Parent Elements:
authorization, sale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

744
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.393 sofort

The sofort element is a child of the sale transaction that, through its child elements, defines
information needed to process an SOFORT (Real-time Bank Transfer) transaction. At this time, you can
use the SOFORT method of payment in Online transactions only.

NOTE: Although included in the schema, this API no longer supports the SOFORT alternate
payment methods. Please consult your Worldpay Relationship Manager for additional information
about SOFORT support.

Parent Elements:
sale

Attributes:
None

Child Elements:
Optional: preferredLanguage

Example: sofort Structure

<sofort>
<preferredLanguage>Country Code of Language</preferredLanguage>
</sofort>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

745
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.394 sofortResponse

The sofortResponse element is a child of the saleResponse transaction when the method of
payment in the request is sofort. It contains child elements that you should store for future
use/reference.

Parent Elements:
saleResponse

Attributes:
None

Child Elements (all Optional):

paymentPurpose, redirectUrl, redirectToken

Example: sofortResponse Structure

<sofortResponse>
<redirectUrl>URL of Vantiv Supplied Mandate</redirectUrl>
<redirectToken>Map Mandate to cnpTxnId</redirectToken>
<paymentPurpose>Reference Number + Billing Descriptor</paymentPurpose>
</sofortResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

746
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.395 ssn

The ssn element is an optional child of the customerInfo element. It is used in combination with
several other elements to provide required information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Pattern; minLength = 4 (last four digits of SSN); maxLength = 9 (full SSN)

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

747
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.396 startDate

The startDate element is a optional child of the subscription element, which specifies the date the
recurring billing should begin. It is also an optional child of both the createAddOn and
createDiscount element, where it specifies either the starting date of the Add On charge or the
starting date of the discount.
Type = Date; Format = YYYY-MM-DD

Parent Elements:
subscription, createAddOn, createDiscount, updateAddOn, updateDiscount

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

748
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.397 state

The state element defines the customer’s state name in the billToAddress, shipToAddress,
taxBilling and elements.
Type = String; minLength = N/A; maxLength = 2

NOTE: Although the schema defines the maxLength for this element as 30, the best practice is to
use the 2 character abbreviation. When submitting an eCheck Verification transaction, you must use
the 2 character abbreviation or the transaction will be rejected with a 370 reason code.

Parent Elements:
billToAddress, shipToAddress, taxExempt

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

749
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.398 submerchantCredit

The submerchantCredit element is the parent element for the transaction type that a Payment
Facilitator uses to move funds from the PayFac Settlement Account to the Sub-merchant Account. If you
use V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundingSubmerchantId, fundsTransferId, submerchantName,
customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

750
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.399 submerchantCreditResponse

The submerchantCreditResponse element is the parent element for information returned to you in
response to a submerchantCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
submerchantCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

751
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.400 submerchantDebit

The submerchantDebit element is the parent element for the transaction type that a Payment
Facilitator uses to move funds from the Sub-merchant Account to the PayFac Settlement Account. If you
use V11.3 or above, you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes For PayFacs, this attribute does not segregate
transactions in iQ. This field does appear in various
SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundingSubmerchantId, fundsTransferId, submerchantName,
customIdentifier

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

752
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.401 submerchantDebitResponse

The submerchantDebitResponse element is the parent element for information returned to you in
response to a submerchantDebit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
submerchantDebit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

753
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.402 submerchantName

The submerchantName element is a required child of the fastAccessFunding, submerchantCredit

and submerchantDebit elements, where it specifies the name of the Sub-merchant impacted by the
funding instruction.
Type = String; minLength = 1; maxLength = 256

Parent Elements:
submerchantCredit, submerchantDebit, fastAccessFunding

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

754
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.403 subscription

The subscription element is a required child of the recurringRequest element and the parent of
several child element that define information about the recurring transaction stream to be handled by the
Recurring Engine.

Parent Elements:
recurringRequest

Attributes:
None

Child Elements (required):

planCode

Child Elements (optional):

numberOfPayments, startDate, amount, createDiscount, createAddOn

NOTE: If you include the numberOfPayments child element, the value submitted overrides the
default value defined in the Plan.

Example: subscription Structure

<subscription>
<planCode>Plan Reference Code</planCode>
<numberOfPayments>1 to 99</numberOfRemianingPayments>
<startDate>Start Date of recurring Cycle</startDate>
<amount>Amount of Recurring Payment</amount>
<createDiscount>
<discountCode>Discount Reference Code</addOnCode>
<name>Name of Discount</name>
<amount>Amount of Discount</amount>
<startDate>Start Date of Discount</startDate>
<endDate>End Date of Discount</endDate>
</createDiscount>
<createAddOn>
<addOnCode>Add On Reference Code</addOnCode>
<name>Name of Add On</name>
<amount>Amount of Add On</amount>
<startDate>Start Date of Add On Charge</startDate>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

755
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<endDate>End Date of Add On Charge</endDate>

</createAddOn>
</subscription>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

756
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.404 subscriptionId

The subscriptionId element is a required child of the recurringResponse element and defines the
assigned identifier for the sequence of recurring billing transactions. You also use this element in the
updateSubscription and cancelSubscription transactions to identify the subscription for
changes/cancellation.
Type = Long; minLength = N/A; maxLength = 19

Parent Elements:
recurringResponse, cnpInternalRecurringRequest, cancelSubscription, updateSubscription,
updateSubscriptionResponse, cancelSubscriptionResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

757
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.405 surchargeAmount

The surchargeAmount element defines the amount of the surcharge applied to the transaction by the
merchant. Supply the value in cents without a decimal point. For example, a value of 400 signifies $4.00.
Type = Integer; totalDigits = 12

NOTE: Use of the surchargeAmount element applies to Visa or Mastercard credit card payments
only. Also, you are required to notify the card networks and us of your intent to applying surcharges
at least 30 days prior to implementing the surcharges. Please consult your Relationship Manager if
you have additional questions.

Parent Elements:
authorization, authReversal, capture, credit, captureGivenAuth, forceCapture, sale

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

758
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.406 systemTraceId

The systemTraceId element is an optional child of the giftCardResponse element, which specifies a
Worldpay generated identifier associated with the transaction in our systems. You should retain this value
for possible future use in gift card reversal transactions.
Type = Integer; totalDigits = 6

Parent Elements:
giftCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

759
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.407 taxAmount

The taxAmount element is a required child of the detailTax element and an optional child of the
lineItemData element and defines the detail tax amount on the purchased good or service. The
decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
Required: detailTax
Optional: lineItemData

NOTE: If you include taxAmount as a child of lineItemData along with detailTax, the
lineItemData taxAmount should be the sum of the taxAmount children from detailTax
children.

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

760
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.408 taxExempt

The taxExempt element is an optional child of the enhancedData element and specifies whether or
not the transaction is exempt from sales tax. If you do not include this element, the value defaults to false.

NOTE: You must set this element to true, if you set the salesTax element to 0.

Type = Boolean; Valid values = true or false

Parent Elements:
enhancedData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

761
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.409 taxIncludedInTotal

The taxIncludedInTotal element is an optional child of the detailTax element and defines whether
or not the tax is included in the total purchase amount.
Type = Boolean; Valid Values = true or false

Parent Elements:
detailTax

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

762
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.410 taxRate

The taxRate element is an optional child of the detailTax element and defines the tax rate applied to
this specific taxable amount.
Type = Decimal; totalDigits = 5

Parent Elements:
detailTax

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

763
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.411 taxType

The taxType element is an optional child of several transaction types that designates the transaction as
either a convenience fee or tax payment for merchants using the Visa Tax Payment Program or the
Mastercard Convenience Fee Program.
Type = String (enum); minLength = N/A; maxLength = 1; Valid Values = payment or fee

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

764
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.412 taxTypeIdentifier

The taxTypeIdentifier element is an optional child of the detailTax element and defines the type
of tax collected on this specific tax amount. If the tax type identifier is unknown, do not include this
element.
Type = String (Enum); minLength = N/A; maxLength = 2

Parent Elements:
detailTax

Attributes:
None
Child Elements:
None

Enumerations:

Enumeration Description

00 Unknown

01 Federal/National Sales Tax

02 State Sales Tax

03 City Sales Tax

04 Local Sales Tax

05 Municipal Sales Tax

06 Other Tax

10 Value Added Tax (VAT)

11 Goods and Services Tax (GST)

12 Provincial Sales Tax (PST)

13 Harmonized Sales Tax (HST)

14 Quebec Sales Tax (QST)

20 Room Tax

21 Occupancy Tax

22 Energy Tax

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

765
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.413 terminalId

The terminalId element is an optional child of the pos element and defines the identifier of the terminal
used at the point of sale.

NOTE: The terrminalId element is required for Mastercard POS transactions.

Type = String; minLength = N/A; maxLength = 8 (No special characters allowed.)

Parent Elements:
pos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

766
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.414 threatMetrixSessionId

NOTE: Starting with V12.3, we have deprecated the use of this element for new or upgrading
merchants. Please use the webSessionId instead. The use and structure is identical.

The threatMetrixSessionId element is an optional child of the advancedFraudChecks element.

Type = String; Allowed Characters = a-z, A-Z, 0-9, -, _ ; minLength = 1; maxLength = 128

NOTE: While generated by you at the time the consumer accesses your page, each
threatMetrixSessionId or webSessionId must include a 5-character prefix, supplied by your
Implementation Consultant, followed by a dash ("-"). The remainder of the Id must be unique for
each instance of the customer accessing your page.

Parent Elements:
advancedFraudChecks

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

767
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.415 token

The token element has three uses depending upon whether the element concerns a Worldpay
generated token (for tokenized merchants) used in a payment transaction, a PayPal generated token, or a
Worldpay token used to convert to a low value token.

NOTE: You also use this element when submitting an Amazon Pay token. In this case, you only
include the cnpToken child element using the Amazon Pay token as the value.

4.415.1 token (structure for card replacement)

In this case, the token element replaces the card element in tokenized card transactions or the echeck
element in Direct Debit transactions, and defines the tokenized payment card/account information.

Parent Elements:
authorization, captureGivenAuth, credit, forceCapture, sale, accountUpdate, updateSubscription,
fastAccessFunding

Attributes:
None

IMPORTANT: Although not a required element, Worldpay recommends you include the expDate
element. If you converted PAN information to tokens using the registerTokenRequest
transaction, we do not have the expDate value stored, so cannot add it to the transaction.
Transactions without expDate have a high likelihood of decline

Child Elements:
Required: cnpToken or tokenUrl (see Note below)

NOTE: Although present in the schema, you can only use the tokenURL element in an Account
Updater request, when requesting the Account Updater service from WPG.

Optional: expDate, cardValidationNum, type, checkoutId

Example: token Structure with cardValidationNumber

<token>
<cnpToken>Token</cnpToken>
<expDate>Card Expiration Date</expDate>
<cardValidationNum>Card Validation Number</cardValidationNum>
<type>Method of Payment</type>
</token>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

768
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: token Structure with checkoutId instead of cardValidationNumber

<token>
<cnpToken>Token</cnpToken>
<expDate>Card Expiration Date</expDate>
<type>Method of Payment</type>
<checkoutId>Low Value Token for CVV</checkoutId>
</token>

4.415.2 token (PayPal generated)

In this case, the token element is the token generated by PayPal.
Type = String; minLength = N/A; maxLength = N/A

Parent Elements:
paypal

Attributes:
None

Child Elements:
None

4.415.3 token (for conversion to LVT)

The token element is a required child of the translateToLowValueTokenRequest. It is the value of
the token you wish to translate to a LVT for use by a third party provider.
Type = String; minLength = N/A; maxLength = 512

Parent Elements:
translateToLowValueTokenRequest

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

769
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.416 tokenMessage

The tokenMessage element provides a short, human-readable explanation of the

tokenResponseCode (see Table 4-4).
Type = String; minLength = N/A; maxLength = N/A

Parent Elements:
tokenResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

770
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.417 tokenResponse

The tokenResponse element is the parent element for several children defining the registered token, as
well the either card type and BIN, or last three characters of the account number in the case of eChecks.
This element appears in the response only if a tokenized merchant submits card or Direct Debit account
information in the transaction request.

Parent Elements:
authorizationResponse, captureGivenAuthResponse, creditResponse, echeckCreditResponse,
echeckRedepositResponse, echeckSalesResponse, echeckVerificationResponse,
forceCaptureResponse, saleResponse, updateSubscriptionResponse

Attributes:
None

Child Elements:
Required: tokenResponseCode, tokenMessage
Optional: cnpToken, type, bin, eCheckAccountSuffix

Example: tokenResponse Structure

<tokenResponse>
<cnpToken>Token</cnpToken>
<tokenResponseCode>Response Code</tokenResponseCode>
<tokenMessage>Response Message</tokenMessage>
<type>Method of Payment</type>
<bin>BIN</bin>
<eCheckAccountSuffix>Last 3 of Account Number</eCheckAccountSuffix> (returned for
eCheck account tokens)
</tokenResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

771
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.418 tokenResponseCode

The tokenResponseCode element provides a 3-digit code (see Table 4-4) indicating the results of a
transaction involving the conversion or attempted conversion of an account number to a token. The
tokenMessage element contains a short, human-readable explanation of the tokenResponseCode.
Type = String; minLength = N/A; maxLength = 3

Parent Elements:
tokenResponse

Attributes:
None

Child Elements:
None

TABLE 4-4 tokenResponseCode and tokenMessage Values

Code Message

801 Account number was successfully registered

802 Account number was previously registered

820 Credit card number was invalid

821 Merchant is not authorized for tokens

822 Token was not found

823 Token was Invalid

898 Generic token registration error

899 Generic token use error

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

772
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.419 tokenUrl

The tokenUrl element is an optional child of the token, originalToken, updatedToken

elements. You use it to submit the token URL value when submitting an Account Updater request via
Access Worldpay. This value must use the following pattern: http.?://.*/.*
Type = String; minLength = N/A; maxLength = 400

NOTE: You can only use the tokenURL element in an Account Updater request, when requesting
the Account Updater service from Access Worldpay.

Parent Elements:
token, updatedToken, originalToken

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

773
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.420 totalHealthcareAmount

The totalHealthcareAmount element is a required child of the healthcareAmounts element and

defines the total amount of healthcare related purchases. This value must be the greater than or equal to
the sum of the values applied to the following elements: RxAmount, visionAmount,
clinicOtherAmount, and dentalAmount. For a Visa transaction, do not include the visionAmount
in the total. The decimal is implied. Example: 500 = $5.00.

NOTE: You must include a value greater than 0, except for a Visa transaction that only includes a
vision component.

Type = Integer; totalDigits = 8

Parent Elements:
Optional: healthcareAmounts

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

774
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.421 track

The track element is child of the card element, which is required for card-present transactions. The
contents of the track element is the data read from the magnetic stripe.
Type = String; minLength = 1; maxLength = 256

Parent Elements:
card

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

775
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.422 track1Status

The track1Status element is a required child of the mpos element. This element indicates whether the
device read track 1 from the magnetic stripe. A value of 0 indicates a successful read, while a value of 1
indicates a failure.
Type = Integer; minInclusive = 0; maxInclusive = 1028

Parent Elements:
mpos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

776
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.423 track2Status

The track2Status element is a required child of the mpos element. This element indicates whether the
device read track 2 from the magnetic stripe. A value of 0 indicates a successful read, while a value of 1
indicates a failure.
Type = Integer; minInclusive = 0; maxInclusive = 1028

Parent Elements:
mpos

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

777
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.424 transactionAmount

The transactionAmount element is an optional child of the applepayResponse element and

specifies the amount of the transaction. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 12

Parent Elements:
applepayResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

778
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.425 transactionId

The transactionId element is used in two locations: in PayPal transactions, as a child of the paypal
element and in Apple Pay transactions as a child of the header element.

4.425.1 transactionId as a Child of the paypal element

The transactionId element is a required child of the paypal element, specifying the transaction Id
returned from PayPal.

NOTE: The value of the <transactionId> element must match the TRANSACTIONID value returned
by the DoExpressCheckoutPayment call operation to PayPal.

Type = String; minLength = N/A; maxLength = N/A

Parent Elements:
paypal

Attributes:
None
Child Elements:
None

4.425.2 transactionId as a Child of the header element

The transctionId element is a required child of the header element and provides the hexadecimal
transaction identifier generated on the device for an Apple Pay transaction.
Type = Hex Encoded String; minLength = N/A; maxLength = 250

Parent Elements:
header

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

779
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.426 translateToLowValueTokenRequest

The translateToLowValueTokenRequest element is the parent element for the transaction type that
creates a low value token for a submitted high value token. You can then provide the low value token to a
third party service provider, who requires access to the PAN information. The third party can redeem the
LVT for the PAN information via an onlineAccountNumberAccessRequest transaction.

NOTE: Please refer to the OmniToken Translator Transaction Info document for additional
information about this transaction type.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

token
Child Elements: (Optional)
orderId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

780
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.427 translateToLowValueTokenResponse

The translateToLowValueTokenResponse element is the parent element for information returned to

you in response to an translateToLowValueTokenRequest transaction. You can then provide the
low value token to a third party service provider, who requires access to the PAN information. The third
party can redeem the LVT for the PAN information via an onlineAccountNumberAccessRequest
transaction.

NOTE: Please refer to the OmniToken Translator Transaction Info document for additional
information about this transaction type.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Load Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Load Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Load Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: response, responseTime, message
Optional: orderId, paypageRegistrationId, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

781
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.428 trialIntervalType

The trialIntervalType element is an optional child of the createPlan element and defines the
interval period of a trial associated with the Plan. The overall length of a trial period is defined by the
trialIntervalType combined with the trialNumberOfIntervals element.
Type = String (enum); minLength = N/A; maxLength = N/A

Parent Elements:
createPlan

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

MONTH The trial interval one month.

DAY The trial interval one day.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

782
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.429 trialNumberOfIntervals

The trialNumberOfIntervals element is an optional child of the createPlan element and defines
the number of trial intervals (trialIntervalType) associated with the Plan. The overall length of a trial
period is defined by the trialIntervalType combined with the trialNumberOfIntervals
element.
Type = Integer; minLength = 1; maxLength = 99

Parent Elements:
createPlan

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

783
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.430 triggeredRule

The triggeredRule element is an optional child of the advancedFraudResult element. It can

appear multiple times in the response, once for each triggered rule from the ThreatMetrix policy. A
triggered rule is one where the threshold is exceeded.
Type = String; minLength = N/A; maxLength = 64

Parent Elements:
advancedFraudResults

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

784
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.431 txnTime

The txnTime element is an optional child of the giftCardResponse element, which specifies the date
and time the transaction was processed by Worldpay. You should retain this value for possible future use
in other gift card transactions, such as giftCardCapture and most reversal transactions. The format of
the element is YYYY-MM-DDTHH:MM:SS. For example, 2016-11-21T11:00:00.
Type = dateTime; minLength = N/A; maxLength = 20

Parent Elements:
giftCardResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

785
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.432 type

The type element has two uses in the cnpAPI depending upon the parent. In one case it defines the type
of account used in the transaction in terms of association, company, PayPal, or Direct Debit. When used
as a child of the fundingSource element, it defines the card type in terms of prepaid, credit, debit, FSA,
or unknown.

4.432.1 type Element as a Child of the parent elements listed below

This type element defines the type of account used in the transaction in terms of card association, card
company, PayPal, or Direct Debit.
Type = String (Enum); minLength = N/A; maxLength = 2

Parent Elements:
accountInformation, newCardInfo, newCardTokenInfo, originalCard, originalCardInfo,
originalCardTokenInfo, originalToken, updatedCard, updatedToken, registerTokenResponse,
tokenResponse, card, paypage, token

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

MC Mastercard

VI Visa

AX American Express

DC Diner’s Club (see Table B-1)

DI Discover

PP PayPal

JC JCB (Japanese Credit Bureau)

EC Direct Debit

GC Gift Card

“” (empty) Card type unknown or undefined

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

786
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.432.2 type Element as a Child of fundingSource

This type element defines the card type in terms of prepaid, credit, debit, FSA, or unknown.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
fundingSource

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

UNKNOWN The card type can not be determined.

PREPAID This is a prepaid card.

CREDIT This is a credit card.

DEBIT This is a debit card.

FSA This is a Flexible Spending Account

card. Cards of this type can be used
only for IRS-approved healthcare items.

NOTE: The fundingSource element and its child elements, type and availableBalance are
associated with the Insights features (see Issuer Insights on page 24.)
Please consult your Relationship Manager for additional information

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

787
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.433 unitCost

The unitCost element is an optional child of the lineItemData element, which specifies the price of
one unit of the item purchased. Although the schema defines it as an optional child of the enhancedData
element, it is required by Visa for Level III interchange rates. The value must be greater than or equal to
0.
Type = Decimal; minInclusive value = 0, totalDigits = 12

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

788
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.434 unitOfMeasure

The unitOfMeasure element is an optional child of the lineItemData element, which specifies the
unit of measure of the purchased item. For example, each, kit, pair, gallon, and month would all be valid
values. Although an optional element, it is required by Visa and Mastercard when specifying line item
data.
Type = String; minLength = 1; maxLength = 12

Parent Elements:
lineItemData

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

789
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.435 unload

The unload element is the parent element for the transaction type that removes funds from a Gift Card.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (all Required)

amount, orderSource, card

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

790
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.436 unloadResponse

The unloadResponse element is the parent element for information returned to you in response to an
unload transaction. It can be a child of either a cnpOnlineResponse element or a batchResponse
element.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Unload transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Unload transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Unload transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, fraudResult, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

791
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.437 unloadReversal

The unloadReversal element is the parent element for the transaction type that reverses the unloading
of a Gift Card.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements: (Required)

card, originalRefCode, originalAmount, originalTxnTime, originalSystemTraceId,
originalSequenceNumber
Child Elements: (Optional)
cnpTxnId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

792
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.438 unloadReversalResponse

The unloadReversalResponse element is the parent element for information returned to you in
response to an unloadReversal transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
Unload Reversal transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
Unload Reversal transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
Unload Reversal transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message
Optional: postDate, giftCardResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

793
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.439 updateAddOn

The updateAddOn element is the parent of several child elements used to modify an additional charge
added to an existing subscription.

Parent Elements:
updateSubscription

Attributes:
None
Child Elements (all Required):
addOnCode, name, amount, startDate, endDate

Example: updateAddOn Structure

<updateAddOn>
<addOnCode>Add On Reference Code</addOnCode>
<name>Name of Add On</name>
<amount>Amount of Add On</amount>
<startDate>Start Date of Add On Charge</startDate>
<endDate>End Date of Add On Charge</endDate>
</updateAddOn>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

794
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.440 updatedCard

The updatedCard element is an optional child of the accountUpdateResponse element, which

contains child elements providing the updated information for the submitted card.

Parent Elements:
accountUpdateResponse

Attributes:
None
Child Elements:
type, number, expDate

Example: updatedCard Structure

<updatedCard>
<type>Card Type</type>
<number>New Account Number</number>
<expDate>New Expiration Date</expDate>
</updatedCard>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

795
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.441 updateCardValidationNumOnToken

The updateCardValidationNumOnToken element is the parent element for the transaction type used
to update a CVV2/CVC2/CID code stored temporarily on the platform. You should only use this
transaction type if you had previously submitted the account number and security code in a
registerTokenRequest transaction and now need to change the CVV2/CVC2/CID value.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpToken, cardValidationNum
Optional: orderId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

796
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.442 updateCardValidationNumOnTokenResponse

The updateCardValidationOnTokenResponse element is the parent element for the response to

updateCardValidationNumOnToken transactions.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
updateCardValidationOnToken transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
updateCardValidationOnToken transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
updateCardValidationOnToken transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, message, responseTime
Optional: location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

797
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.443 updateDiscount

The updateDiscount element is the parent of several child elements used to define updates to a
discount applied to an existing subscription.

Parent Elements:
updateSubscription

Attributes:
None
Child Elements (all Required):
discountCode, name, amount, startDate, endDate

Example: customerInfo Structure

<updateDiscount>
<discountCode>Discount Reference Code</discountCode>
<name>Name of Discount</name>
<amount>Amount of Discount</amount>
<startDate>Start Date of Discount</startDate>
<endDate>End Date of Discount</endDate>
</updateDiscount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

798
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.444 updatePlan

The updatePlan element is the parent of the transaction used to activate/deactivate Plans associated
with recurring payments. When you deactivate a Plan, you can no longer reference that Plan for use with
subscriptions. Existing subscriptions making use of the deactivated Plan will continue to use the Plan until
either modified or completed. You can also reactivate a deactivated Plan by updating the Plan and setting
the active flag to true.

Parent Elements:
cnpOnlineRequest, cnpRequest

Attributes:
None

Child Elements:
planCode, active

Example: createPlan Structure

<updatePlan>
<planCode>Plan Reference Code</planCode>
<active>true or false</active>
</updatePlan>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

799
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.445 updatePlanResponse

The updatePlanResponse element is the parent of the response message to the updatePlan
transaction used to deactivate Plans associated with recurring payments.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:
None

Child Elements:
cnpTxnId, response, message, responseTime, planCode, location

Example: updatePlan Structure

<updatePlan>
<cnpTxnId>Transaction ID</cnpTxnId>
<response>Response Reason Code</response>
<message>Response Message</message>
<location>Processing Platfom Location</location>
<responseTime>Date and Time in GMT</responseTime>
<planCode>Plan Reference Code</planCode>
</updatePlan>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

800
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.446 updateSubscription

The updateSubscription element is the parent element for the transaction that updates the
subscription information associated with a recurring payment. Using this transaction type you can change
the plan, card, billing information, and/or billing date. You can also create, update, or delete a Discount
and/or an Add On.

Parent Elements:
cnpOnlineRequest, batchRequest

Attributes:
None

Child Elements:
Required: subscriptionId
Optional: planCode, billToAddress, (choice of) card, paypage, or token, billingDate, createDiscount,
deleteDiscount, updateDiscount, createAddOn, updateAddOn, deleteAddOn

Example: updateSubscription - Change Plan

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<planCode>New Plan Code</planCode>
</updateSubscription>

Example: updateSubscription - Change Card

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<card>
<type>Card Type Abbreviation</type>
<number>Account Number</number>
<expDate>Expiration Date</expDate>
</card>
</updateSubscription>

Example: updateSubscription - Change Billing Date

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<billingDate>New Billing Date</billingDate>
</updateSubscription>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

801
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: updateSubscription - Change Billing Info

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<billToAddress>
<name>Customer’s Full Name</name>
<companyName>Company’s Name</companyName>
<addressLine1>Address Line 1</addressLine1>
<addressLine2>Address Line 2</addressLine2>
<addressLine3>Address Line 3</addressLine3>
<city>City</city>
<state>State Abbreviation</state>
<zip>Postal Code</zip>
<country>Country Code</country>
<email>Email Address</email>
<phone>Telephone Number</phone>
</billToAddress>
</updateSubscription>

Example: updateSubscription - Create Discount

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<createDiscount>
<discountCode>Discount Reference Code</discountCode>
<name>Name of Discount</name>
<amount>Amount of Discount</amount>
<startDate>Start Date of Discount</startDate>
<endDate>End Date of Discount</endDate>
</createDiscount>
</updateSubscription>

Example: updateSubscription - Create Add On

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<createAddOn>
<addOnCode>Add On Reference Code</addOnCode>
<name>Name of Add On</name>
<amount>Amount of Add On</amount>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

802
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

<startDate>Start Date of Add On Charge</startDate>

<endDate>End Date of Add On Charge</endDate>
</createAddOn>
</updateSubscription>

Example: updateSubscription - Update Discount

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<updateDiscount>
<discountCode>Discount Reference Code</discountCode>
<name>Name of Discount</name>
<amount>Amount of Discount</amount>
<startDate>Start Date of Discount</startDate>
<endDate>End Date of Discount</endDate>
</updateDiscount>
</updateSubscription>

Example: updateSubscription - Update Add On

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<updateAddOn>
<addOnCode>Add On Reference Code</addOnCode>
<name>Name of Add On</name>
<amount>Amount of Add On</amount>
<startDate>Start Date of Add On Charge</startDate>
<endDate>End Date of Add On Charge</endDate>
</updateAddOn>
</updateSubscription>

Example: updateSubscription - Delete Discount

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<deleteDiscount>
<discountCode>Discount Reference Code</discountCode>
</deleteDiscount>
</updateSubscription>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

803
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

Example: updateSubscription - Delete Add On

<updateSubscription>
<subscriptionId>Subscription Id</subscriptionId>
<deleteAddOn>
<addOnCode>Add On Reference Code</addOnCode>
</deleteAddOn>
</updateSubscription>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

804
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.447 updateSubscriptionResponse

The updateSubscriptionresponse element is the parent element for the response to an

updateSubscription transaction.

Parent Elements:
cnpOnlineResponse, batchResponse

Attributes:
None

Child Elements:
subscriptionId, cnpTxnId, response, message, responseTime, tokenResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

805
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.448 updatedToken

The updatedToken element is an optional child of the accountUpdateResponse element, which

contains child elements providing the updated information for the submitted token.

Parent Elements:
accountUpdateResponse

Attributes:
None
Child Elements:
cnpToken or tokenUrl, type, number, expDate, bin

Example: updatedToken Structure (with cnpToken)

<updatedToken>
<cnpToken>New Token Number</cnpToken>
<expDate>New Expiration Date</expDate>
<type>Card Type</type>
<bin>Card BIN</bin>
</updatedToken>

Example: updatedToken Structure (with tokenUrl)

<updatedToken>
<tokenUrl>New Token URL</tokenUrl>
<expDate>New Expiration Date</expDate>
<type>Card Type</type>
<bin>Card BIN</bin>
</updatedToken>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

806
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.449 url

The url element is an optional child of the customBilling element. You use it to designate your
customer service web site instead of providing a customer service phone number. This element may
include any of the following characters: A-Z, a-z, 0-9, /, \, -, ., or _.
Type = String; minLength = N/A; maxLength = 13

NOTE: Please consult your Relationship Manager prior to attempting to use the <url> element.
This contents of this element are discarded unless you are specifically enabled to use in your
cnpAPI submissions.

Parent Elements:
customBilling

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

807
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.450 user

The user element is a required child of the authentication element. It is a unique identifier of the
user/merchant used to authenticate that the message is from a valid source.
Type = String; minLength = N/A; maxLength = 20

Parent Elements:
authentication

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

808
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.451 vendorCredit

The vendorCredit element is the parent element for the transaction type that a Payment Facilitator or a
qualified direct merchant uses to move funds from the PayFac/Merchant Settlement Account to the
Vendor Account. A Payment Facilitator must include the fundingSubmerchantId element, while a
direct merchant must include the fundingCustomeId element.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
Note: For Payment Facilitators, this attribute does not
segregate transactions in iQ. This field does appear in
various SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundsTransferId, vendorName and choice of fundingSubmerchantId or
fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

809
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.452 vendorCreditResponse

The vendorCreditResponse element is the parent element for information returned to you in response
to a vendorCredit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
submerchantCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

810
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.453 vendorDebit

The vendorDebit element is the parent element for the transaction type that a Payment Facilitator uses
to move funds from the Vendor Account to the PayFac Settlement Account. If you use V11.3 or above,
you can submit this transaction type either in a Batch or Online.

Parent Elements:
batchRequest, cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
Note: For Payment Facilitators, this attribute does not
segregate transactions in iQ. This field does appear in
various SSR reports.
minLength = 1 maxLength = 25

Child Elements:
Required: accountInfo, amount, fundsTransferId, vendorName, and choice of fundingSubmerchantId or
fundingCustomerId

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

811
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.454 vendorDebitResponse

The vendorDebitResponse element is the parent element for information returned to you in response
to a vendorDebit transaction.

Parent Elements:
batchResponse, cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
payFacCredit transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
payFacCredit transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
submerchantCredit transaction.
minLength = 1 maxLength = 25

duplicate boolean No If the request is a duplicate, the response includes the

duplicate flag set to true and the entire original
response.
Note: This attribute applies only to Online Dynamic
Payout Funding Instruction responses.

Child Elements:
Required: cnpTxnId, fundsTransferId, response, responseTime, message
Required (Online): postDate, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

812
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.455 vendorName

The vendorName element is a required child of both the vendorCredit and vendorDebit elements
and specifies the name of the vendor involved in the funding instructions.
Type = String; minLength = 1; maxLength = 256

Parent Elements:
vendorCredit, vendorDebit

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

813
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.456 verificationCode

NOTE: This element is not used at this time.

The verificationCode element is an optional child of the echeckSaleResponse element. It

specifies the verification code from the associated eCheck Sale transaction.
Type = String; minLength = N/A; maxLength = 6

Parent Elements:
echeckSalesResponse

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

814
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.457 verify

The verify element is an optional child of the echeckSale element, which allows you to specify to
perform an eCheck Verification prior to processing the sale. If the account fails the verification operation,
the system does not process the sale.
Type = Boolean; Valid Values = true or false

Parent Elements:
echeckSale

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

815
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.458 version

The version element is a required child of the applepay element and provides version information
about the payment token.
Type = String; minLength = 5; maxLength = 20

Parent Elements:
applepay

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

816
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.459 virtualAccountNumber

The virtualAccountNumber element is an optional child of the enhancedAuthResponse element

and indicates if the card number used for the transaction corresponds to a virtual account number.
Type = Boolean; Valid Values = true or false

Parent Elements:
enhancedAuthResponse

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

817
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.460 virtualGiftCard

The virtualGiftCard element is an optional child of the activate transaction. You include this
element when you are requesting a Virtual Gift Card.

NOTE: In an early iteration of schema V8.22 issued in September of 2013 the

accountNumberLength and giftCardBin child elements were defined as optional. If you coded
to the earlier version, be aware that these elements are now required children of
virtualGiftCard. If you do not include these elements, the transaction will fail XML validation.

Parent Elements:
activate

Attributes:
None
Child Elements (all required):
accountNumberLength, giftCardBin

Example: virtualGiftCard Structure

<virtualGiftCard>
<accountNumberLength>Length of Virtual Card Number</accountNumberLength>
<giftCardBin>Requested BIN of Virtual Gift Card</giftCardBin>
</virtualGiftCard>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

818
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.461 virtualGiftCardBin

The VirtualGiftCardBin element is an optional child of the activateReversal element defining

the BIN of the virtual Gift Card.
Type = String; minLength = N/A; maxLength = 10

Parent Elements:
activateReversal

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

819
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.462 virtualGiftCardResponse

The virtualGiftCardResponse element is an optional child of the activateResponse transaction.

This element is returned when you request a Virtual Gift Card number via an activate transaction and
through its children, defines the virtual gift Card number.

Parent Elements:
activateResponse

Attributes:
None
Child Elements (all optional):
accountNumber, pin

Example: virtualGiftCardResponse Structure

<virtualGiftCardResponse>
<accountNumber>Virtual Card Number</accountNumber>
<pin>Pin Number</pin>
</virtualGiftCardResponse>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

820
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.463 visionAmount

The visionAmount element is an optional child of the healthcareAmounts element and defines the
healthcare amount used for vision related purchases. The decimal is implied. Example: 500 = $5.00.
Type = Integer; totalDigits = 8

Parent Elements:
Optional: healthcareAmounts

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

821
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.464 void

The void element is the parent element for all Void transactions. You can use this element only in Online
transactions. If you use this Recycling Engine, you can use the void transaction to halt the recycling of a
sale transaction.

NOTE: Before submitting a Void, please allow a minimum of 60 seconds to elapse after submitting
the transaction you wish to void. This timing ensures our system fully records the first (to be voided)
transaction in our database.

Parent Elements:
cnpOnlineRequest

Attributes:

Attribute Name Type Required? Description

id String Yes A unique identifier assigned by the presenter and

mirrored back in the response.
minLength = 1 maxLength = 36

customerId String No A value assigned by the merchant to identify the

consumer.
minLength = N/A maxLength = 50

reportGroup String Yes Required attribute that defines the merchant

sub-group in the user interface where this transaction
will be displayed. Please refer to Coding for Report
Groups on page 10 for additional information.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId
Optional: processingInstructions

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

822
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.465 voidResponse

The voidResponse element is the parent element for information returned to you in response to a Void
transaction.

Parent Elements:
cnpOnlineResponse

Attributes:

Attribute Name Type Required? Description

id String Yes The response returns the same value submitted in the
void transaction.
minLength = 1 maxLength = 36

customerId String No The response returns the same value submitted in the
void transaction.
minLength = N/A maxLength = 50

reportGroup String Yes The response returns the same value submitted in the
void transaction.
minLength = 1 maxLength = 25

Child Elements:
Required: cnpTxnId, response, responseTime, message, postDate
Optional: recyclingResponse, location

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

823
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.466 wallet

The wallet element is an optional child of the of both the authorization and sale transactions.
You must use this element along with its child elements, when the consumer uses MasterPass or Visa
Checkout to make a purchase.

Parent Elements:
authorization, sale

Attributes:
None
Child Elements:
walletSourceType, walletSourceTypeId

Example: wallet Structure

<wallet>
<walletSourceType>MasterPass or VisaCheckout</walletSourceType>
<walletSourceTypeId>MasterPass ID or VCIND</walletSourceTypeId>
</wallet>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

824
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.467 walletSourceType

The walletSourceType element is a required child of the wallet element, which defines the source of
the transaction information. You must submitted this element with the transaction when the consumer
uses MasterPass or Visa Checkout.
Type = String (Enum); minLength = N/A; maxLength = N/A

Parent Elements:
wallet

Attributes:
None

Child Elements:
None

Enumerations:

Enumeration Description

MasterPass The origin of the information used in the

transaction is from MasterPass.

VisaCheckout The origin of the information used in the

transaction is from Visa Checkout.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

825
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.468 walletSourceTypeId

The walletSourceTypeId element is a required child of the wallet element. For MasterPass
transactions, the value of this element is returned from MasterPass. For Visa Checkout transactions, set
this value to VCIND.
Type = String; minLength = N/A; maxLength = N/A

Parent Elements:
wallet

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

826
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.469 webSessionId

The webSessionId element is an optional child of the advancedFraudChecks element. You use this
Id to identify a particular transaction to our suite of Fraud Tools, allowing the correlation of data, scores,
and fraud results.
Type = String; Allowed Characters = a-z, A-Z, 0-9, -, _ ; minLength = 1; maxLength = 128

NOTE: While generated by you at the time the consumer accesses your page, each
webSessionId must include a 5-character prefix, supplied by your Implementation Consultant,
followed by a dash ("-"). The remainder of the Id must be unique for each instance of the customer
accessing your page.
If you use V12.3 or above, you must use the webSessionId to provide the Id value, not the
threatMetrixSessionId element.

Parent Elements:
advancedFraudChecks

Attributes:
None

Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

827
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.470 yearsAtEmployer

The yearsAtEmployer element is an optional child of the customerInfo element and defines the
number of years the customer has worked for their current employer. It is used in combination with
several other elements to provide required information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Integer; totalDigits = 2

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

828
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.471 yearsAtResidence

The yearsAtResidence element is an optional child of the customerInfo element and defines the
number of years the customer has resided in their current domicile. It is used in combination with several
other elements to provide required information for some PayPal Credit transactions.

NOTE: V12 and above do not support PayPal Credit transactions.

Type = Integer; totalDigits = 2

Parent Elements:
customerInfo

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

829
© 2020 FIS and/or its affiliates. All rights reserved.
 cnpAPI Elements

4.472 zip

The zip element defines the customer’s postal code in both the billToAddress and shipToAddress
elements.
Type = String; minLength = N/A; maxLength = 20

NOTE: Although the schema specifies the maxLength of the zip element as 20 characters, in
practice you should never exceed 10 characters in your submissions.
If including the zip element for eCheck Verification, do not exceed 9 characters and do not use
dashes.

Parent Elements:
billToAddress, shipToAddress

Attributes:
None
Child Elements:
None

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

830
© 2020 FIS and/or its affiliates. All rights reserved.
 A
Payment Transaction Response Codes

This appendix provides reference material regarding the codes that are returned in a cnpAPI response for
a payment transaction. This appendix contains the following sections:
• Payment Transaction Response Codes
• 3DS Authentication Result Codes
• AVS Response Codes
• AAVS Response Codes
• Card Validation Response Codes
• Advanced Fraud Tools Triggered Rules
• XML Validation Error Messages
• Additional Response Header Error Messages
• ACH Return Reason Codes
• ACH NoC Change Codes
• Canadian EFT Return Codes

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

831
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.1 Payment Transaction Response Codes

This section contains a list of codes and messages that the system can return in the response message
for a payment transaction.

NOTE: For information concerning Chargeback Response Code, see the Chargeback API
Reference Guide.

Table A-1 shows all possible values for the <response> and <message> elements. You should code
appropriately to handle all codes applicable to the transactions you use.
• The Response Code value appears in the <response> element.
• The Response Message value appears in the <message> element.

TABLE A-1 Valid Values for the Response and Message Elements

Response Response
Code Response Message Type Description

001 Transaction Received Info This is sent to acknowledge that the

submitted transaction has been received.
Note: This response applies only to V10.x
versions of the API.

000 Approved Approved No action required.

010 Partially Approved Approved The authorized amount is less than the
requested amount.

011 Offline Approval Approved Offline approval issued while the terminal is
unable to communicate with the issuer.

013 Offline Approval (unable to go Approved Offline approval issued while the terminal is
online) unable to communicate with the issuer.

100 Processing Network Unavailable Soft There is a problem with the card or PINless
Decline Debit network. Contact the network for more
information.

101 Issuer Unavailable Soft There is a problem with the issuer network.
Decline Please contact the issuing bank.

102 Re-submit Transaction Soft There is a temporary problem with your

Decline submission. Please re-submit the
transaction.

108 Try again later Soft Returned if the eProtect token is not
immediately available, when submitting an
Auth or Sale transaction.

110 Insufficient Funds Soft The card does not have enough funds to
Decline cover the transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

832
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

111 Authorization amount has already Hard The total amount of the original
been depleted Decline Authorization has been used.
Appears in Declined Transaction report.

120 Call Issuer Referral or There is an unspecified problem, contact the

Soft issuing bank.
Decline

121 Call AMEX Referral There is an unspecified problem; contact

AMEX.

122 Call Diners Club Referral There is an unspecified problem; contact

Diners Club.

123 Call Discover Referral There is an unspecified problem; contact

Discover.

124 Call JBS Referral There is an unspecified problem; contact

JBS.

125 Call Visa/Mastercard Referral There is an unspecified problem; contact

Visa or Mastercard.

126 Call Issuer - Update Cardholder Referral Some data is out of date; contact the issuer
Data to update this information.

127 Exceeds Approval Amount Limit Hard This transaction exceeds the daily
Decline approval limit for the card.

130 Call Indicated Number Referral There is an unspecified problem; contact the
phone number provided.

140 Update Cardholder Data Referral Cardholder data is incorrect; contact the
issuing bank.

150 Original transaction found. Info A Query transaction response indicating that
the original transaction was found.

151 Original transaction not found. Info A Query transaction response indicating that
the original transaction was not found.

152 Original transaction found, but Info A Query transaction response indicating that
response not yet available. the original transaction was found, but the
final response information is not yet
available.

153 Query transaction not enabled. Info A Query transaction response indicating that
you are not enabled for use of the Query
transaction.

154 At least one of origId or Soft When submitting a Query transaction, you
origCnpTxnId is required Decline must include either the origId or
origCnpTxnId.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

833
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

155 origCnpTxnId is required when Soft When submitting a Query transaction with
showStatusOnly is used Decline the showStatusOnly flag set to Y, you
must include the origCnpTxnId element.

170 Submitted MCC not allowed Hard The submitted MCC is not part of the
Decline allowed MCC white list. Resubmit the
transaction with an allowed MCC, or ask
your Relationship Manager about adding
the submitted MCC to the white list.

191 The merchant is not registered in N/A This is an Account Updater response
the update program. indicating a set-up problem that must be
resolved prior to submitting another request
file. Escalate this to your Relationship
Manager.

192 Merchant not certified/enabled for Hard Your organization is not certified or
IIAS Decline enabled for IIAS/FSA transactions.

206 Issuer Generated Error Soft An unspecified error was returned by the
Decline issuer. Please retry the transaction and if the
problem persist, contact the issuing bank.

207 Pickup card - Other than Hard The issuer indicated that the gift card
Lost/Stolen Decline should be removed from use.

209 Invalid Amount Hard The specified amount is invalid for this
Decline transaction.

211 Reversal Unsuccessful Hard The reversal transaction was

Decline unsuccessful.

212 Missing Data Hard Contact your Relationship Manager.

Decline

213 Pickup Card - Lost Card Hard The submitted card was reported as lost
Decline and should be removed from use.

214 Pickup Card - Stolen Card Hard The submitted card was reported as
Decline stolen and should be removed from use.

215 Restricted Card Hard The specified Gift Card is not available
Decline for use.

216 Invalid Deactivate Hard The Deactivate transaction is invalid for

Decline the specified card.

217 Card Already Active Hard The submitted card is already active.
Decline

218 Card Not Active Hard The submitted card has not been
Decline activated.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

834
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

219 Card Already Deactivate Hard The submitted card has already been
Decline deactivated.

221 Over Max Balance Hard The activate or load amount exceeds the
Decline maximum allowed for the specified gift
Card.

222 Invalid Activate Hard The activate transaction is not valid or

Decline can no longer be reversed.

223 No transaction Found for Hard The transaction referenced in the

Reversal Decline reversal transaction does not exist.

226 Incorrect CVV Hard The transaction was declined because it

Decline was submitted with the incorrect security
code.

229 Illegal Transaction Hard The transaction would violate the law.
Decline

251 Duplicate Transaction Hard The transaction is a duplicate of a

Decline previously submitted transaction.
Appears in Declined Transaction report.

252 System Error Hard Contact your Relationship Manager.

Decline

253 Deconverted BIN Hard The BIN is no longer valid.

Decline

254 Merchant Depleted Hard No balance remains on gift Card.

Decline

255 Gift Card Escheated Hard The Gift Card has been seized by the
Decline government while resolving an estate.

256 Invalid Reversal Type for Credit Hard You attempted to use a Closed Loop Gift
Card Transaction Decline Card reversal transaction to reverse a
credit card transaction. For example, you
cannot use a Deposit Reversal
transaction to reverse a Capture. To
reverse a credit card Capture transaction,
use a Credit transaction.

257 System Error (message format Hard Issuer reported message format is
error) Decline incorrect. Contact your Relationship
Manager.

258 System Error (cannot process) Hard Issuer reported transaction could not be
Decline processed. Contact your Relationship
Manager.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

835
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

271 Refund rejected due to pending Soft The refund is tied to a deposit that is still in
deposit status Decline pending state or the state is in doubt. You
can retry the refund at a later time.

272 Refund rejected due to declined Hard The refund is tied to a deposit that failed.
deposit status Decline

273 Refund rejected by the processing Soft The refund is tied to a deposit that
network Decline succeeded, but was declined by PayPro.

284 Capture, Credit and AuthReversal Hard You must use the Gift Card version of
tags cannot be used for Gift Card Decline these transactions for Gift Cards (i.e.,
Transactions giftCardCapture, giftCardCredit, and
giftCardAuthReversal).

301 Invalid Account Number Hard The account number is not valid; contact
Decline the cardholder to confirm information or
inquire about another form of payment.

302 Account Number Does Not Match Hard The payment type was selected as one
Payment Type Decline card type (e.g. Visa), but the card number
indicates a different card type (e.g.
Mastercard).

303 Pick Up Card Hard This is a card present response, but in a

Decline card not present environment. Do not
process the transaction and contact the
issuing bank.

304 Lost/Stolen Card Hard The card has been designated as lost or
Decline stolen; contact the issuing bank.

305 Expired Card Hard The card is expired.

Decline

306 Authorization has expired; no Hard The original Authorization is no longer

need to reverse Decline valid, because it has expired. You can
not perform an Authorization Reversal
for an expired Authorization.
Appears in Declined Transaction report.

307 Restricted Card Hard The card has a restriction preventing

Decline approval for this transaction. Please
contact the issuing bank for a specific
reason.
You may also receive this code if the
transaction was declined due to Prior
Fraud Advice Filtering and you are using
a schema version V8.10 or older.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

836
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

308 Restricted Card - Chargeback Hard This transaction is being declined due
Decline the operation of the Prior Chargeback
Card Filtering Service or the card has a
restriction preventing approval if there
are any chargebacks against it.

309 Restricted Card - Prepaid Card Hard This transaction is being declined due
Filtering Service Decline the operation of the Prepaid Card
Filtering service.

310 Invalid track data Hard The track data is not valid.
Decline

311 Deposit is already referenced by a Hard The deposit is already referenced by a

chargeback Decline chargeback; therefore, a refund cannot
be processed against the original
transaction.
Appears in Declined Transaction report.

312 Restricted Card - International Hard This transaction is being declined due
Card Filtering Service Decline the operation of the International Card
Filtering Service.

313 International filtering for issuing Hard This is returned when the transaction
card country <country> Decline involves a US based merchant
processing Canadian transactions has a
(where <country> is the 3-character
transaction that uses a US card.
country code)

315 Restricted Card - Auth Fraud Hard This transaction is being declined due
Velocity Filtering Service Decline the operation of the Auth Fraud Velocity
Filtering Service.

316 Automatic Refund Already Issued Hard This refund transaction is a duplicate for
Decline one already processed automatically by
the Fraud Chargeback Prevention
Service (FCPS).
Appears in Declined Transaction report.

318 Restricted Card - Auth Fraud Hard This transaction is being declined due
Advice Filtering Service Decline the operation of the Auth Fraud Advice
Filtering Service.

319 Restricted Card - Fraud AVS Hard This transaction is being declined due
Filtering Service Decline the operation of the Auth Fraud AVS
Filtering Service.

320 Invalid Expiration Date Hard The expiration date is invalid

Decline

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

837
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

321 Invalid Merchant Hard The card is not allowed to make

Decline purchases from this merchant (e.g. a
Travel only card trying to purchase
electronics).

322 Invalid Transaction Hard The transaction is not permitted; contact

Decline the issuing bank.
Note: If you are enabled for
Transaction Filtering, but have not The system also returns this code if you
upgraded to use schema version 8.3 attempt to use a Void transaction to cancel a
or above, the system returns this Gift Card transaction.
code for transactions filtered by the
Prepaid or International Card
Filtering Service. If you are enabled
for Velocity Fraud Filtering, but have
not upgraded to V8.9, you will
receive this code for filtered
transactions. If you are enabled for
AVS Fraud Filtering, but have not
upgraded to V8.13, you will receive
this code for filtered transactions.

323 No such issuer Hard The card number references an issuer

Decline that does not exist. Do not process the
transaction.

324 Invalid Pin Hard The PIN provided is invalid.

Decline Appears in Declined Transaction report

325 Transaction not allowed at Hard The transaction is not permitted; contact
terminal Decline the issuing bank.

326 Exceeds number of PIN entries Hard (Referring to a debit card) The incorrect
Decline PIN has been entered excessively and
the card is locked.

327 Cardholder transaction not Hard Merchant does not allow that card type or
permitted Decline specific transaction.

328 Cardholder requested that Hard Recurring/Installment Payments no

recurring or installment payment Decline longer accepted by the card issuing
be stopped bank.

330 Invalid Payment Type Hard This payment type is not accepted by the
Decline issuer.

331 Invalid POS Capability for Hard For a Cardholder Authorized Terminal
Cardholder Authorized Terminal Decline Transaction the POS capability must be
Transaction set to magstripe.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

838
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

332 Invalid POS Cardholder ID for Hard For a Cardholder Authorized Terminal
Cardholder Authorized Terminal Decline Transaction the POS Cardholder ID must
Transaction be set to nopin.

335 This method of payment does not Hard You can not perform an Authorization
support authorization reversals Decline Reversal transaction for this payment
type.

336 Reversal amount does not match Hard For a merchant initiated reversal against
Authorization amount. Decline an American Express authorization, the
reversal amount must match the
authorization amount exactly.

337 Transaction did not convert to Soft Retry the transaction.

Pinless Decline

340 Invalid Amount Hard The transaction amount is invalid (too

Decline high or too low). For example, less than 0
for an authorization, or less than .01 for
other payment types.

341 Invalid Healthcare Amounts Hard The amount submitted with this
Decline FSA/Healthcare transaction is invalid.
The FSA amount must be greater than 0,
and cannot be greater than the
transaction amount.

346 Invalid billing descriptor prefix Hard The billing descriptor prefix submitted is
Decline not valid.
Appears in Declined Transaction report.

347 Invalid billing descriptor Hard The billing descriptor is not valid
Decline because you are not authorized to send
transactions with custom billing fields.
Appears in Declined Transaction report.

348 Invalid Report Group Hard The Report Group specified in the
Decline transaction is invalid, because it is either
not in the defined list of acceptable
Report Groups or there is a mis-match
between the Report Group and the
defined Billing Descriptor.

349 Do Not Honor Soft The issuing bank has put a temporary hold
Decline on the card.

350 Generic Decline Soft or There is an unspecified problem; contact the

Hard issuing bank for more details.
Decline
Note: This code can be a hard or soft
decline, depending on the method of
payment, and other variables.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

839
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

351 Decline - Request Positive ID Hard Card Present transaction that requires a
Decline picture ID match.

352 Decline CVV2/CID Fail Hard The CVV2/CID is invalid.

Decline

354 3-D Secure transaction not Hard You are not certified to submit 3-D
supported by merchant Decline Secure transactions.

356 Invalid purchase level III, the Soft Submitted Level III data is bad or missing.
transaction contained bad or Decline
missing data

357 Missing healthcareIIAS tag for an Hard The FSA Transactions submitted does
FSA transaction Decline not contain the <healtcareIIAS> data
element.

358 Restricted by Vantiv due to Hard The transaction was declined due to the
security code mismatch. Decline security code (CVV2, CID, etc) not
matching.

360 No transaction found with Hard There were no transactions found with
specified Transaction Id Decline the specified Transaction Id.
Appears in Declined Transaction report.

361 Authorization no longer available Hard The authorization for this transaction is
Decline no longer available. Either the
authorization has already been
consumed by another capture, or the
authorization has expired.
Appears in Declined Transaction report.

362 Transaction Not Voided - Already Hard This transaction cannot be voided; it has
Settled Decline already been delivered.
Appears in Declined Transaction report.

363 Auto-void on refund Hard This transaction (both capture and

Decline refund) has been voided.
Appears in Declined Transaction report.

364 Invalid Account Number - original Hard The submitted account number is invalid.
or NOC updated eCheck account Decline Confirm the original account number or
required check NOC for new account number.

365 Total credit amount exceeds Hard The amount of the credit is greater than
capture amount Decline the capture, or the amount of this credit
plus other credits already referencing
this capture are greater than the capture
amount.
Appears in Declined Transaction report.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

840
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

366 Exceed the threshold for sending Hard NACHA rules allow two redeposit
redeposits Decline attempts within 180 days of the
settlement date of the initial deposit
attempt. This threshold has been
exceeded.
Appears in Declined Transaction report.

367 Deposit has not been returned for Hard NACHA rules only allow redeposit
insufficient/non-sufficient funds Decline attempts against deposits returned for
Insufficient or Uncollected Funds.
Appears in Declined Transaction report.

368 Invalid check number Soft The check number is invalid.

Decline

369 Redeposit against invalid Hard The redeposit attempted against an

transaction type Decline invalid transaction type.
Appears in Declined Transaction report.

370 Internal System Error - Call Vantiv Hard There is a problem with the system.
Decline Contact
[email protected].

371 Original Transaction has been Hard Do not send additional redeposit
Processed - Future Redeposits Decline transactions, since the original
Canceled transaction was processed.
Appears in Declined Transaction report.

372 Soft Decline - Auto Recycling In Soft The transaction was intercepted because it
Progress Decline is being auto recycled by the Recycling
Engine.

373 Hard Decline - Auto Recycling Hard The transaction was intercepted because
Complete Decline auto recycling has completed with a final
decline.

375 Merchant is not enabled for Hard The submitted transaction contained a
surcharging Decline surcharge and the merchant is not
enabled for surcharging.

376 This method of payment does not Hard The use of a surcharge is only allowed
support surcharging Decline for Visa and Mastercard methods of
payment.

377 Surcharge is not valid for debit or Hard You cannot apply a surcharge to a
prepaid cards Decline transaction using a debit or prepaid card.

378 Surcharge cannot exceed 4% of Hard The surcharge in the submitted

the sale amount Decline transaction exceeded 4% maximum
allowed for a surcharge.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

841
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

379 Transaction declined by the Hard The SEPA Direct Debit processing
processing network Decline network declined the transaction for
unspecified reasons. Some possible
reasons are: insufficient funds,
IBAN/Name disagreement, red flag on
account, etc.

380 Secondary amount cannot exceed Hard The secondary amount exceeded the sale
the sale amount Decline amount in the submitted transaction.

381 This method of payment does not Hard The submitted method of payment does
support secondary amount Decline not allow the use of Convenience Fees.

382 Secondary amount cannot be less Hard The secondary amount must be a
than zero Decline positive integer.

383 Partial transaction is not Hard Transactions set to allow partial

supported when including a Decline authorizations cannot include a
secondary amount secondary amount.

384 Secondary amount required on Hard If the associated sale or capture

partial refund when used on Decline transaction included a secondary
deposit amount, an associated partial refund
must include a secondary amount.

385 Secondary amount not allowed Hard If the associated sale or capture
on refund if not included on Decline transaction did not included a secondary
deposit amount, you cannot include a secondary
amount on an associated refund.

386 Processing Network Error Soft Worldpay is experiencing issues

Decline communicating with the SEPA Direct Debit
network. Please retry the transaction.

401 Invalid E-mail Hard The e-mail address provided is not valid.
Decline Verify that it was entered correctly.

469 Invalid Recurring Request - See Hard The Recurring Request was invalid,
Recurring Response for Details Decline which invalidated the transaction. The
Response Code and Message in the
Recurring Response contains additional
information.

470 Approved - Recurring Subscription Approved The recurring request was processed
Created successfully.

471 Parent Transaction Declined - Hard The original payment transaction was
Recurring Subscription Not Decline declined, so the recurring payments have
Created not been scheduled.
Appears in Declined Transaction report.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

842
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

472 Invalid Plan Code Hard The plan specified in the recurring
Decline request was invalid.

473 Scheduled Recurring Payment Approved The scheduled recurring payment has been
Processed processed successfully.

475 Invalid Subscription Id Hard The referenced subscription Id does not

Decline exist.
Appears in Declined Transaction report.

476 Add On Code Already Exists Hard The specified Add On code already
Decline exists.
Appears in Declined Transaction report.

477 Duplicate Add On Codes in Hard Multiple createAddOn requests

Requests Decline submitted with the same Add On Code.

478 No Matching Add On Code for the Hard The Add On code specified does not
Subscription Decline exist.
Appears in Declined Transaction report.

480 No Matching Discount Code for Hard The Discount Code supplied in the
the Subscription Decline updateDiscount or deleteDiscount
transaction does not exist.
Appears in Declined Transaction report.

481 Duplicate Discount Codes in Hard Multiple createDiscount requests

Request Decline submitted with the same Discount Code.

482 Invalid Start Date Hard The supplied Start Date is invalid.
Decline

483 Merchant Not Registered for Hard You are not registered for the use of the
Recurring Engine Decline Recurring Engine.

484 Insufficient data to update Hard The transaction did not include data
subscription Decline needed for update operation.

485 Invalid Billing Date Hard The submitted billing date is either
Decline before the current date or otherwise
invalid.

486 Discount Code Already Exists Hard The specified Discount code already
Decline exists.

487 Plan Code already exists Hard The specified Plan Code already exists.
Decline

500 The account number was Hard An Account Updater response indicating
changed Decline the Account Number changed from the
original number.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

843
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

501 The account was closed Hard An Account Updater response indicating
Decline the account was closed. Contact the
cardholder directly for updated
information.

502 The expiration date was changed N/A An Account Updater response indicating the
Expiration date for the card has changed.

503 The issuing bank does not N/A An Account Updater response indicating the
participate in the update program issuing bank does not participate in the
update program

504 Contact the cardholder for updated N/A An Account Updater response indicating you
information should contact the cardholder directly for
updated information.

505 No match found N/A An Account Updater response indicating no

match was found in the updated information.

506 No changes found N/A An Account Updater response indicating

there have been no changes to the account
information.

507 The cardholder has opted out of the N/A The cardholder requested that no updates
update program be included for their account.

521 Soft Decline - Card reader Soft The connection to the decryption service is
decryption service is not available Decline currently unavailable. Please retry the
transaction and/or contact your Relationship
Manager.

523 Soft Decline - Decryption failed Soft Our attempt to decrypt the card information
Decline failed. Please retry the transaction.

524 Hard Decline - Input data is Hard The submitted data is invalid.
invalid. Decline

530 Apple Pay Key Mismatch Hard The submitted publicKeyHash element
Decline does not match any configured entries.
Contact your Implementation Consultant.

531 Apple Pay Decryption Failed Hard Worldpay was unable to decrypt the
Decline submitted information.

540 Hard Decline - Decryption Failed Hard Worldpay was unable to decrypt the
Decline submitted card number and/or CVV.

550 Advanced Fraud Filter Score Hard The transaction was declined because
Below Threshold Decline the resulting Fraud Filter Score was
below the acceptable threshold set in the
merchant’s policy.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

844
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

560 System Error - Contact Worldpay Soft There was an unspecified problem with the
representative Decline transaction. Please contact your Worldpay
Relationship Manager.

561 Amazon Pay - Amazon Unavailable Soft Amazon was unavailable. Please retry the
Decline transaction.

562 Amazon Pay - Amazon Declined Hard Amazon declined the transaction.
Decline

563 Amazon Pay - Invalid Token Hard The submitted Amazon token is invalid.
Decline Please correct the token value before
resubmitting the transaction.
Make a GetChargePermisson call to the
AmazonPay API to determine the current
state of the token. If the token is Closed,
you cannot execute new authorizations.
If the token is Open, but with a
PaymentPlanNotSet constraint, you must
re-engage the buyer to update theie
Payment Method Details (i.e., Expiry
Date, Billing Address, etc.)

564 Merchant not enabled for Amazon Hard Your organization is not enabled for the
Pay Decline use of Amazon Pay. Please contact your
Relationship Manager.

601 Soft Decline - Primary Funding Soft A PayPal response indicating the
Source Failed Decline transaction failed due to an issue with
primary funding source (e.g. expired Card,
insufficient funds, etc.).

NOTE: The Response Message associated with Response Code 602 is inaccurate due to a remapping of
PayPal Response Codes. Please read the Description below for the recommended action when receiving
Response Code 602.

602 Soft Decline - Buyer has alternate Soft The transaction could not be completed for
funding source Decline one of the following reasons:
• The billing address associated with the
financial Instrument could not be
confirmed.
• The transaction exceeds the card limit.
• The transaction was denied by the card
issuer.
You should establish error handling logic
that directs the customer to contact PayPal
to resolve the issue with their account.

610 Hard Decline - Invalid Billing Hard A PayPal response indicating the Billing
Agreement Id Decline Agreement ID is invalid.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

845
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

611 Hard Decline - Primary Funding Hard A PayPal response indicating the issuer
Source Failed Decline is unavailable.

612 Hard Decline - Issue with Paypal Hard A PayPal response indicating the
Account Decline transaction failed due to an issue with
the buyer account.

613 Hard Decline - PayPal Hard A PayPal response indicating the need to
authorization ID missing Decline correct the authorization ID before
resubmitting.

614 Hard Decline - confirmed email Hard A PayPal response indicating your
address is not available Decline account is configured to decline
transactions without a confirmed
address. request another payment
method or contact
[email protected] to
modify your account settings.

615 Hard Decline - PayPal buyer Hard A PayPal response indicating account
account denied Decline unauthorized payment risk.

616 Hard Decline - PayPal buyer Hard A PayPal response indicating PayPal is
account restricted Decline unable to process the payment. Buyer
should contact PayPal with questions.

617 Hard Decline - PayPal order has Hard A PayPal response indicating no further
been voided, expired, or Decline authorizations/captures can be
completed processed against this order. A new
order must be created.

618 Hard Decline - issue with PayPal Hard A PayPal response indicating one of
refund Decline these potential refund related issues:
duplicate partial refund must be less than
or equal to original or remaining amount,
past time limit, not allowed for
transaction type, consumer account
locked/inactive, or complaint exists - only
a full refund of total/remaining amount
allowed. Contact
[email protected] for
specific details.

619 Hard Decline - PayPal credentials Hard A PayPal response indicating you do not
issue Decline have permissions to make this API call.

620 Hard Decline - PayPal Hard A PayPal response indicating you cannot
authorization voided or expired Decline capture against this authorization. You
need to perform a brand new
authorization for the transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

846
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

621 Hard Decline - required PayPal Hard A PayPal response indicating missing
parameter missing Decline parameters are required. Contact
[email protected] for
specific details.

622 Hard Decline - PayPal transaction Hard A PayPal response indicating the need to
ID or auth ID is invalid Decline check the validity of the authorization ID
prior to reattempting the transaction.

623 Hard Decline - Exceeded Hard A PayPal response indicating you should
maximum number of PayPal Decline capture against a previous authorization.
authorization attempts

624 Hard Decline - Transaction Hard A PayPal response indicating the

amount exceeds merchant’s Decline transaction amount exceeds the
PayPal account limit. merchant’s account limit. Contact
[email protected] to
modify your account settings.

625 Hard Decline - PayPal funding Hard A PayPal response indicating the buyer
sources unavailable. Decline needs to add another funding sources to
their account.

626 Hard Decline - issue with PayPal Hard A PayPal response indicating there are
primary funding source. Decline issues with the buyer’s primary funding
source.

627 Hard Decline - PayPal profile does Hard Contact your Relationship Manager to
not allow this transaction type. Decline adjust your PayPal merchant profile
preferences.

628 Internal System Error with PayPal Hard There is a problem with your username
- Contact Vantiv Decline and password. Contact
[email protected].

629 Hard Decline - Contact PayPal Hard A PayPal response indicating you should
consumer for another payment Decline contact the consumer for another
method payment method.

637 Invalid terminal Id Hard The terminal Id submitted with the POS
Decline transaction is invalid.

640 PINless Debit processing not Hard At this time, we support PINless Debit
supported for non-recurring Decline transaction only for recurring
transactions transactions.

641 PINless Debit processing not Hard PINless Debit does not support partial
supported for partial auths Decline authorizations. You can resubmit the
transaction without using the partial auth
flag.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

847
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

642 Merchant not configured for Hard You are not enabled for PINless Debit
PINless Debit processing Decline processing. Please consult your
Relationship Manager for additional
information about this feature.

651 Decline - Customer Cancellation Hard

Decline

652 Decline - Re-try Transaction Soft

Decline

653 Decline - Unable to locate record Soft

on file Decline

654 Decline - File update field edit Soft

error Decline

655 Remote function unknown Soft

Decline

656 Decline - Exceeds Withdrawal Soft

Frequency Limit Decline

657 Decline - Card Record not Soft

Available Decline

658 Invalid Authorization Code Soft

Decline

659 Decline - Reconciliation Error Soft

Decline

660 Decline - Preferred Debit Routing Soft

Denial: Credit transaction can be Decline
debit

661 Decline - Currency Conversion Soft

Complete, No Auth Performed Decline
(1st Pass)

662 Decline - Multi-Currency DCC Soft

Failure Decline

663 Decline - Multi-Currency Invert Soft

Failure Decline

664 Invalid 3-D Secure Password Hard

Decline

665 Invalid Social Security Number Hard

Decline

666 Invalid Mother’s Maiden Name Hard

Decline

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

848
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

667 Enrollment Inquiry Decline Soft

Decline

668 Social Security Number not Hard

Available Decline

669 Mother’s Maiden Name not Hard

Available Decline

670 PIN Already Exists on Database Hard

Decline

701 Under 18 years old Hard A PayPal Credit response indicating the
Decline customer is under 18 years of age based
upon the date of birth.

702 Bill to outside USA Hard A PayPal Credit response indicating the
Decline billing address is outside the United
States.

703 Bill to address is not equal to Hard A PayPal Credit response indicating that
ship to address Decline the billing address does not match the
shipping address.

704 Declined, foreign currency, must Hard A PayPal Credit or PINless Debit
be USD Decline response indicating the transaction is
declined, because it is not in US dollars.

705 On negative file Hard A PayPal Credit response indicating the

Decline account is on the negative file.

706 Blocked agreement Hard A PayPal Credit response indicating a

Decline blocked agreement account status.

707 Insufficient buying power Other A PayPal Credit response indicating that the
account holder does not have sufficient
credit available for the transaction amount.

708 Invalid Data Hard A PayPal Credit response indicating that

Decline there are one or more problems with the
submitted data.

709 Invalid Data - data elements Hard A PayPal Credit response indicating one
missing Decline or more required data elements are
missing.
Also, returned for an Direct Debit
transaction that is missing a required
data element. For example, failure to
include the name element in an
echeckSale or echeckCredit
transaction would result in this code
being returned.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

849
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

710 Invalid Data - data format error Hard A PayPal Credit response indicating that
Decline some data was formatted incorrectly.

711 Invalid Data - Invalid T&C version Hard A PayPal Credit response indicating the
Decline T&C version is invalid.

712 Duplicate transaction Hard A PayPal Credit response indicating that

Decline- the transaction is a duplicate.

713 Verify billing address Hard A PayPal Credit response indicating that
Decline you should verify the billing address.

714 Inactive Account Hard A PayPal Credit response indicating the

Decline customer account is inactive.

716 Invalid Auth Hard A PayPal Credit response indicating that

Decline the referenced authorization is invalid.

717 Authorization already exists for Hard A PayPal Credit response indicating that
the order Decline an authorization already exists for the
transaction.

730 Lodging transactions are not Hard Your current MCC does not allow lodging
allowed for this MCC Decline transactions. Please consult your
Relationship Manager.

731 Duration cannot be negative Hard You submitted a negative value for the
Decline <duration> element. Correct the error
and resubmit the transaction.

732 Hotel Folio Number cannot be Hard Although the schema does not require
blank Decline the submission of the
<hotelFolioNumber> element, if you do
include it, you must specify a value (i.e.,
null not allowed). Please either add a
valid value or remove the element and
resubmit the transaction.

733 Invalid check in date Hard There is a problem with the submitted
Decline check in date (for example, 2018-02-32).
Please correct the date and resubmit the
transaction.

734 Invalid check out date Hard There is a problem with the submitted
Decline check out date (for example, 2018-02-32).
Please correct the date and resubmit the
transaction.

735 Invalid check in or check out date Hard There is a problem with the submitted
Decline check in or check out date (for example,
2018-02-32). Please correct the date(s)
and resubmit the transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

850
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

736 Check out date cannot be before Hard The check out date you submitted was
check in date Decline before the check in date. Correct the
error and resubmit the transaction.

737 Number of adults cannot be Hard You submitted a negative value for the
negative Decline <numAdult> element. Correct the error
and resubmit the transaction.

738 Room rate cannot be negative Hard You submitted a negative value for the
Decline <roomRate> element. Correct the error
and resubmit the transaction.

739 Room tax cannot be negative Hard You submitted a negative value for the
Decline <roomTax> element. Correct the error
and resubmit the transaction.

740 Duration can only be from 0 to 99 Hard For Visa the maximum duration is 99
for Visa Decline (2-digits).

801 Account number was successfully Approved The card number was successfully
registered registered and a token number was
returned.

802 Account number was previously Approved The card number was previously registered
registered for tokenization.
Note: You also receive this response code
when using a low value token in a
transaction, because the system registers
the PAN at the time it creates the LVT.

803 Valid Token Approved The token is valid.

805 Card Validation Number Updated Approved The stored value for CVV2/CVC2/CID has
been successfully updated.

820 Credit card number was invalid Hard The card number submitted for
Decline tokenization is invalid.

821 Merchant is not authorized for Hard Your organization is not authorized to
tokens Decline use tokens.

822 Token was not found Hard The token number submitted with this
Decline transaction was not found.

823 Token Invalid Hard The submitted token is invalid.

Decline

825 Merchant not authorized for Hard Your organization is not authorized for
eCheck tokens Decline Direct Debit tokenization.

826 Checkout Id was invalid Soft The submitted checkoutId is invalid.

Decline

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

851
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

827 Checkout Id was not found Soft The submitted checkoutId was not found.
Decline The low value token is only good for 24
hours and may have expired.

828 Generic Checkout Id error Soft An unknown error caused the use of
Decline checkoutId to fail.

835 Capture amount can not be more Hard The amount in the submitted Capture
than authorized amount Decline exceeds 115% of the authorized amount.
Appears in Declined Transaction report.

850 Tax Billing only allowed for MCC Hard Tax Billing elements are allowed only for
9311 Decline MCC 9311.

851 MCC 9311 requires taxType Hard Missing taxType element

element Decline

852 Debt Repayment only allowed for Hard You must be either MCC 6012 or 6051 to
VI transactions on MCCs 6012 Decline designate a Visa transaction as Debt
and 6051 Repayment (debtRepayment element set
to true).

861 Routing Number did not match one Soft The routing number submitted does not
on file for token Decline match the number submitted when the token
was created. Verify the routing number and
resubmit the transaction.

877 Invalid Pay Page Registration Id Hard An eProtect response indicating that the
Decline Registration ID submitted is invalid.

878 Expired Pay Page Registration Id Hard An eProtect response indicating that the
Decline Registration ID has expired (Registration
IDs expire 24 hours after being issued).

879 Merchant is not authorized for Hard Your organization is not authorized to
Pay Page Decline use eProtect.

890 Maximum number of updates for Hard

this token exceeded Decline

891 Too many tokens created for Hard

existing namespace Decline

892 Token expired or will expire Hard

within 5 days Decline

898 Generic token registration error Soft There is an unspecified token registration
Decline error; contact your Relationship Manager

899 Generic token use error Soft There is an unspecified token use error;
Decline contact your Relationship Manager.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

852
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

900 Invalid Bank Routing Number Hard The Direct Debit routing number
Decline submitted with this transaction has failed
validation.

901 Missing Name Hard The customer name is required for SEPA
Decline transactions.

902 Invalid Name Hard The customer name must be a minimum

Decline of two characters for SEPA transactions.

903 Missing Billing Country Code Hard The Billing Country code is required for
Decline SEPA transactions.

904 Invalid IBAN Hard The submitted International Bank Account

Decline number is invalid. Please correct the number
and resubmit the traction.

905 Missing Email Address Hard The customer email address is required
Decline for SEPA transactions.

906 Missing mandate reference Hard You must provide a Mandate reference
Decline for standard and BYOM recurring SEPA
deposit transactions.

907 Invalid mandate reference Hard The Mandate reference is invalid. It must
Decline conform to the following format: 1 to 35
characters consisting of alphanumeric,
colon, question mark, forward slash,
plus, parenthesis, comas, period, space,
and dash. The applicable regular
expression is: ^[A-Za-z0-9:?/+(),. -]{1,35}$

908 Missing mandate URL Hard You must provide a Mandate URL for
Decline SEPA Bring Your Own Mandate deposit
transactions (both one-time and
recurring).

909 Invalid mandate URL Hard The Mandate URL must start with https
Decline and be followed by 5 to 120 characters
adhering to the following regular
expression: ^https://.{5,120}$

911 Missing mandate signature date Hard You must provide a Mandate signature
Decline date for SEPA Bring Your Own Mandate
deposit transactions (both one-time and
recurring).

912 Invalid mandate signature date Hard You must provide a Mandate signature
Decline date earlier than or the same as the
current date with the following format:
YYYY-MM-DD.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

853
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

913 Recurring mandate already exists Hard Worldpay returns this message when you
Decline submit multiple first Bring Your Own
Mandate recurring transactions with the
same mandate reference. The mandate
references among the recurring
transactions for a single merchant must
be unique.

914 Recurring mandate was not found Hard Worldpay returns this message when you
Decline submit a subsequent or final standard
recurring transaction before a first
standard recurring is processed and
confirmed.

915 Final recurring was already Hard Worldpay returns this message when you
received using this mandate Decline submit a first or subsequent recurring
transaction after we received a final
recurring. The life cycle of a recurring
mandate ends after the processing of a
final recurring deposit transaction. This
applies to both standard and Bring Your
Own Mandate recurring transactions.

916 IBAN did not match one on file for Hard Worldpay returns this message when you
mandate Decline submit a subsequent or final recurring
with a different IBAN than the IBAN used
in the first recurring transaction. This
applies to both standard and Bring Your
Own Mandate recurring transactions.
Note: If a customer wants to use a
different IBAN for a recurring SEPA
mandate, they must use a request for
another mandate reference using this
new IBAN.

917 Invalid Billing Country Hard Some of the alternative payment

Decline methods restrict the allowed consumer's
billing country codes. For example,
iDEAL only allows country code NL.

940 This Funding Instruction results in a Soft There are insufficient funds in the FBO
negative account balance Decline Settlement Account to cover the Funding
Instruction. Wait for additional funds to settle
to the account and then resubmit the
transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

854
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

941 Account balance information Soft Typically, this response occurs only for new
unavailable at this time. Decline FBO Settlement accounts that do not yet
have any settled transactions and were not
pre-funded (i.e., no balance yet recorded for
the account). Wait for additional funds to
settle to the account or pre-fund the account
and then resubmit the transaction.

942 The submitted card is not eligible Hard The card you submitted in the Fast
for Fast Access Funding. Decline Access Funding instruction cannot
receive funds using this method.

943 Transaction cannot use both Hard A transaction can not contain both the
ccdPaymentInformation and Decline ccdPaymentInformation and
ctxPaymentInformation ctxPaymentInformation elements.

944 Processing Error Soft Please retry the transaction.

Decline

945 This funding Instruction Hard Currently, the following Funding

transaction type is invalid for Decline Instruction transaction types are not
Canadian merchants supported in Canada: reserveCredit,
reserveDebit, physicalCheckCredit,
physicalCheckDebit, and
fastAccessFunding.

946 CTX and CCD records are not Hard the ccdPaymentInformation and
allowed for Canadian merchants Decline ctxPaymentInformation elements are not
permitted for Canadian merchants.

950 Decline - Negative Information on Hard An Direct Debit response indicating the
File Decline account is on the negative file.

951 Absolute Decline Hard An Direct Debit response indicating that

Decline this transaction was declined.

952 The Merchant Profile does not Hard An Direct Debit response indicating that
allow the requested operation Decline your Merchant Profile does not allow the
requested operation. Contact your
Relationship Manager for additional
information.

953 The account cannot accept ACH Hard An Direct Debit response indicating the
transactions Decline customer’s checking account does not
accept ACH transactions.

954 The account cannot accept ACH Hard An Direct Debit response indicating the
transactions or site drafts Decline customer’s checking account does not
accept ACH transactions or site drafts.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

855
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-1 Valid Values for the Response and Message Elements (Continued)

Response Response
Code Response Message Type Description

955 Amount greater than limit Hard A Direct Debit response indicating that
specified in the Merchant Profile Decline the dollar amount of this transaction
exceeds the maximum amount specified
in your Merchant Profile. Contact your
Relationship Manager for additional
information.

956 Merchant is not authorized to Hard A Direct Debit response indicating that
perform eCheck Verification Decline your organization is not authorized to
transactions perform eCheck verifications. Contact
your Relationship Manager for additional
information.

957 First Name and Last Name Hard A Direct Debit response indicating that
required for eCheck Verifications Decline the first and last name of the customer is
required for eCheck verifications.

958 Company Name required for Hard A Direct Debit response indicating that
corporate account for eCheck Decline the company name is required for
Verifications verifications on corporate accounts.

959 Phone number required for Hard A Direct Debit response indicating that
eCheck Verifications Decline the phone number of the customer is
required for echeck verifications.

961 Card Brand token not supported Hard This code is returned if the merchant
Decline submits a Visa generated token.

962 Private Label Card not supported Hard This code is returned if the transaction
Decline involves a Visa Private Label card.

980 Soft Decline - Customer Soft The submitted transaction requires

Authentication Required Decline Customer Authentication

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

856
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.2 3DS Authentication Result Codes

Table A-2 contains a list of valid authentication result codes returned by Visa for the Verified by Visa
service or Mastercard for the Mastercard SecureCode service. It specifies which authentication result
values apply to which order sources.

NOTE: The Mastercard Secure Code service only returns values of 0 or 1, indicating a downgrade.
If Mastercard did not return a result code, the 3DS authentication succeeded.
The Discover ProtectBuy service only returns one of the following Authentication Result Codes: 0, 1,
or 2.

TABLE A-2 Authentication Result Codes

Authentication
Result Code Description

Order Source - Ecommerce

Blank CAVV not present or CAVV not verified. Issuer has not selected
CAVV verification option.

Order Source - any

B CAVV passed verification, but no liability shift because a) ECI was

not 5 or 6 or b) the card type is an excluded (e.g., Commercial Card)

Order Source - 3DSAuthenticated or 3DSAttempted

0 CAVV could not be verified or CAVV data was not provided when
expected
or (for Mastercard)
Downgrade to non-3DS transaction, Missing or base64 encoded AAV
does not start with j (AAV is invalid for 3dsAuthenticated transaction)

6 CAVV not verified, because Issuer not participating. VisaNet

processes as if CAVV is valid.

Order Source - 3DSAuthenticated

1 CAVV failed verification

or (for Visa)
TAVV (token authentication verification value) cryptogram failed
validation
or (for Mastercard)
Downgrade to 3DS Attempted transaction, AAV starts with h and not
j

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

857
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-2 Authentication Result Codes (Continued)

Authentication
Result Code Description

2 CAVV passed verification

or (for Visa)
TAVV cryptogram passed validation

D Issuer elected to return CAVV verification results and Field 44.13

blank. Value is set by VisaNet; means CAVV Results are valid.

Order Source - 3DSAttempted

3 CAVV passed verification

or (for Visa)
DTVV (dynamic token verification value) or Visa-defined format
cryptogram failed validation

4 CAVV failed verification - attempted authentication

or (for Visa)
DTVV or Visa-defined format cryptogram passed validation

5 Not used

7 CAVV failed verification

8 CAVV passed verification

9 CAVV failed verification; Visa generated CAVV because Issuer ACS

was not available.

A CAVV passed verification; Visa generated CAVV because Issuer

Access Control Server (ACS) was not available.

B CAVV passed verification but no liability shift because a) ECI was not
5 or 6 or b) the card type is an excluded (e.g., Commercial Card)

C Issuer elected to return CAVV verification results and Field 44.13

blank. Value is set by VisaNet; means CAVV Results are valid

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

858
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.3 AVS Response Codes

Table A-3 contains a list of AVS response codes that can be returned in the response for a payment
transaction. There are some codes that you may never receive. Code your system to expect codes from
this list. The description is not included in the response.

TABLE A-3 AVS Response Codes

AVS Response Code Description

00 5-Digit zip and address match

01 9-Digit zip and address match

02 Postal code and address match (International)

10 5-Digit zip matches, address does not match

11 9-Digit zip matches, address does not match

12 Zip does not match, address matches

13 Postal code does not match, address matches

14 Postal code matches, address not verified

20 Neither zip nor address match

30 AVS service not supported by issuer

31 AVS system not available

32 Address unavailable

33 General error

34 AVS not performed

40 Address failed Worldpay edit checks

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

859
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.4 AAVS Response Codes

Table A-4 contains a list of American Express Advanced AVS response codes that can be returned as
verification of information supplied in the <name>, <phone> and/or <email> child elements of the
<billToAddress> element. The system returns the AAVS response code in the
<advancedAVSResult> child of the <fraudResult> element.
The code returned has the following format:
• 1st position - name match
• 2nd position - phone match
• 3rd position - email match
• Each position can have one of the following values:
– 0 - No Match (failure)
– 1 - Match
– 2 - Not Sent
– 3 - No Response (unchecked, retry, or service not allowed)
For example, a code of 210 would indicate that the name was not sent, the phone matches, and the email
does not match.
You should code your system to parse all codes from this list. The description is not included in the
response.

TABLE A-4 Advances AVS Response Codes

AAVS Response
Code Description

000 No Match

001 Email matches, name and phone do not match

002 Name and phone do not match, email not sent

003 Name and phone do not match, no response for email

010 Phone matches, name and email do not match

011 Phone and email match, name does not match

012 Phone matches, name does not match, email not sent

013 Phone matches, name does not match, no response for

email

020 Name and email do not match, phone not sent

021 Email matches, name does not match, phone not sent

030 Name and email do not match, no response for phone

031 Email matches, name does not match, no response for

phone

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

860
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-4 Advances AVS Response Codes

AAVS Response
Code Description

033 Name does not match, no response for phone or email

100 Name matches, phone and email do not match

101 Name and email match, phone does not match

102 Name matches, phone does not match, email not sent

103 Name matches, phone does not match, no response for

email

110 Name and phone match, no match for email

111 Full match

112 Name and phone match, email not sent

113 Name and phone match, no response for email

120 Name matches, email does not match, phone not sent

121 Name and email match, phone not sent

130 Name matches, email does not match, no response for

phone

131 Name and email match, no response for phone

133 Name matches, no response for phone or email

200 Name not sent, phone and email do not match

201 Email matches, phone does not match, name not sent

202 Phone does not match, name and email not sent

203 Phone does not match, name not sent, no response for
email

210 Phone matches, email does not match, name not sent

211 Phone and email match, name not sent

212 Phone matches, name and email not sent

213 Phone matches, name not sent, no response for email

220 Email does not match, name and phone not sent

221 Email matches, name and phone not sent

230 Email does not match, name not sent, no response for
phone

231 Email matches, name not sent, no response for phone

233 Name not sent, no response for phone and email

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

861
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-4 Advances AVS Response Codes

AAVS Response
Code Description

300 Phone and email do not match, no response for name

301 Email matches, phone does not match, no response for

name

302 Phone does not match, no response for name, email not
sent

303 Phone does not match, no response for name and email

310 Phone matches, email does not match, no response for

name

311 Phone and email match, no response for name

312 Phone matches, email not sent, no response for name

313 Phone matches, no response for name and email

320 Email does not match, phone not sent, no response for
name

321 Email matches, phone not sent, no response for name

330 Email does not match, no response for name and phone

331 Email matches, no response for name and phone

333 No response

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

862
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.5 Card Validation Response Codes

Table A-5 contains a normalized list of response codes that can be returned when requesting a card
validation check.
• CVV2
• CVC2
• CID
The description is not included in the response.

NOTE: For American Express transactions, if the submitted security code does not match, the
transaction is declined with a Response Reason Code of 352 - Decline CVV2/CID Fail.

TABLE A-5 Card Validation Response Codes

CVV2/CVC2/CID
Response Code Description

M Match

N No Match

P Not Processed

S CVV2/CVC2/CID should be on the card, but the merchant

has indicated CVV2/CVC2/CID is not present

U Issuer is not certified for CVV2/CVC2/CID processing

“” (empty response) Check was not done for an unspecified reason

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

863
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.6 Advanced Fraud Tools Triggered Rules

This section provides definitions of the triggered rules returned in the Advanced Fraud Results
(advancedFraudResults element) section of the response message (see Example below).
ThreatMetrix uses the rules triggered by each advanced fraud check to determine the device reputation
score, which in turn determines the final review status: Pass, Review, or Fail.

NOTE: The rules/descriptions in this document reflect those used in the generic merchant policy.
Depending upon the policy configured in your merchant profile, some rules may not apply to you, or
additional rules, not defined here, may appear in your results.

Example: advancedFraudResults Structure

<advancedFraudResults>
<deviceReviewStatus>pass, fail, review, etc.</deviceReviewStatus>
<deviceReputationScore>Score Returned from ThreatMetrix</deviceReputationScore>
<triggeredRule>Triggered Rule #1</triggeredRule>
.
.
.
<triggeredRule>Triggered Rule #N</triggeredRule>
</advancedFraudResults>

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This device submitted 10 or more payments in

10PaymentsOnDeviceLocalDay the previous 24 hours. This is atypical and may
be an indicator of misuse.
This device has submitted 10 or more payments
10PaymentsOnDeviceLocalHour in the previous hour. This is atypical and may be
an indicator of misuse.
This device appears to have submitted 10 or
10PaymentsOnFuzzyDeviceLocalDay more payments in the previous 24 hours. This is
atypical and may be an indicator of misuse.
This device appears to have submitted 10 or
10PaymentsOnFuzzyDeviceLocalHour more payments in the previous hour. This is
atypical and may be an indicator of misuse.
This True IP submitted 10 or more payments in
10PaymentsOnTrueIPLocalDay the previous day. This is atypical and may be an
indicator of misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

864
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This True IP submitted 10 or more payments in

10PaymentsOnTrueIPLocalHour the previous hour. This is atypical and may be an
indicator of misuse.
This email address submitted 10 or more
10PaymentsWithEmailAddressLocalDay payments in the previous day. This is atypical
and may be an indicator of misuse.
This customer ID submitted 15 or more payments
15PaymentsWithCustomerIDLocalDay in the previous day. This is atypical and may be
an indicator of misuse.
This payment card submitted 15 or more
15PaymentsWithPaymentCardLocalDay payments in the previous day. This is atypical
and may be an indicator of misuse.
This device submitted 100 or more payments in
100PaymentsOnDeviceLocalMonth the previous month. This is atypical and may be
an indicator of misuse.
This device appears to have submitted 100 or
100PaymentsOnFuzzyDeviceLocalMonth more payments in the previous month. This is
atypical and may be an indicator of misuse.
This True IP submitted 100 or more payments in
100PaymentsOnTrueIPLocalMonth the previous month. This is atypical and may be
an indicator of misuse.
This device used 2 or more screen resolutions in
2ScreenResolutionsPerDeviceGlobalDay the past day. This is atypical and may indicate
misuse.
This device submitted 20 or more payments in
20PaymentsOnDeviceLocalDay the previous 24 hours. This is atypical and may
be an indicator of misuse.
This device appears to have submitted 20 or
20PaymentsOnFuzzyDeviceLocalDay more payments in the previous 24 hours. This is
atypical and may be an indicator of misuse.
This True IP submitted 20 or more payments in
20PaymentsOnTrueIPLocalDay the previous day. This is atypical and may be an
indicator of misuse.
This customer ID submitted 20 or more payments
20PaymentsWithCustomerIDLocalWeek in the previous week. This is atypical and may be
an indicator of misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

865
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This payment card submitted 20 or more

20PaymentsWithPaymentCardLocalWeek payments in the previous week. This is atypical
and may be an indicator of misuse.
This device submitted transactions using 3 or
more distinct customer IDs in the previous 24
3CustomerIDsPerDeviceLocalDay
hours. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.
This device submitted transactions using 3 or
more distinct customer IDs in the previous 7
3CustomerIDsPerDeviceLocalWeek
days. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.
Three or more devices have been used to submit
3DevicesPerCustomerIDLocalDay transactions with this customer ID in the previous
24 hours. This may be an indicator of misuse.
Three or more devices have been used to submit
3DevicesPerCustomerIDLocalWeek transactions with this customer ID in the previous
7 days. This may be an indicator of misuse.
Three or more devices have been used to submit
transactions with this email address in the
3DevicesPerEmailGlobalDay
previous 24 hours. This may be an indicator of
misuse.
Three or more devices have been used to submit
transactions with this email address in the
3DevicesPerEmailGlobalWeek
previous 7 days. This may be an indicator of
misuse.
Three or more devices have been used to submit
transactions with this payment card in the
3DevicesPerPaymentCardGlobalDay
previous 24 hours. This may be an indicator of
misuse.
Three or more devices have been used to submit
transactions with this payment card in the
3DevicesPerPaymentCardGlobalWeek
previous 7 days. This may be an indicator of
misuse.
This device has submitted transactions using 3 or
more distinct email addresses in the previous 24
3EmailsPerDeviceGlobalDay
hours. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

866
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This device has submitted transactions using 3 or

more distinct email addresses in the previous 7
3EmailsPerDeviceGlobalWeek
days. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.
This device appears to have submitted
transactions using 3 or more distinct email
3EmailsPerFuzzyDeviceLocalHour addresses in the previous 60 minutes. This is
abnormal and may be an indicator of a
card-testing attack or free-trial abuse.
This device has submitted transactions using 3 or
more distinct payment cards in the previous 24
3PaymentCardsPerDeviceGlobalDay
hours. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.
This device has submitted transactions using 3 or
more distinct payment cards in the previous 7
3PaymentCardsPerDeviceGlobalWeek
days. This is abnormal and may be an indicator
of a card-testing attack or free-trial abuse.
This device has submitted 3 or more payments in
3PaymentsOnDeviceLocalHour the previous hour. This is atypical and may be an
indicator of misuse.
This device appears to have submitted 3 or more
3PaymentsOnFuzzyDeviceLocalHour payments in the previous hour. This is atypical
and may be an indicator of misuse.
This True IP submitted 3 or more payments in
3PaymentsOnTrueIPLocalHour the previous hour. This is atypical and may be an
indicator of misuse.
This device submitted transactions through 3 or
more distinct IP proxies in the previous 24 hours.
3ProxiesPerDeviceGlobalDay
This is atypical and may be an indicator of
misuse.
This device has used 4 or more screen
4ScreenResolutionsPerDeviceGlobalDay resolutions in the past day. This is atypical and
may indicate misuse.
This device has submitted 5 or more payments in
5PaymentsOnDeviceLocalDay the previous 24 hours. This is atypical and may
be an indicator of misuse.
This device has submitted 5 or more payments in
5PaymentsOnDeviceLocalHour the previous hour. This is atypical and may be an
indicator of misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

867
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This device appears to have submitted 5 or more

5PaymentsOnFuzzyDeviceLocalDay payments in the previous 24 hours. This is
atypical and may be an indicator of misuse.
This device appears to have submitted 5 or more
5PaymentsOnFuzzyDeviceLocalHour payments in the previous hour. This is atypical
and may be an indicator of misuse.
This True IP has submitted 5 or more payments
5PaymentsOnTrueIPLocalDay in the previous day. This is atypical and may be
an indicator of misuse.
This True IP submitted 5 or more payments in
5PaymentsOnTrueIPLocalHour the previous hour. This is atypical and may be an
indicator of misuse.
This customer ID submitted 5 or more payments
5PaymentsWithCustomerIDLocalHour in the previous hour. This is atypical and may be
an indicator of misuse.
This email address has submitted 5 or more
5PaymentsWithEmailAddressLocalHour payments in the previous hour. This is atypical
and may be an indicator of misuse.
This payment card submitted 5 or more
5PaymentsWithPaymentCardLocalHour payments in the previous hour. This is atypical
and may be an indicator of misuse.
This device has submitted 50 or more payments
50PaymentsOnDeviceLocalWeek in the previous week. This is atypical and may be
an indicator of misuse.
This device appears to have submitted 50 or
50PaymentsOnFuzzyDeviceLocalWeek more payments in the previous week. This is
atypical and may be an indicator of misuse.
This True IP has submitted 50 or more payments
50PaymentsOnTrueIPLocalMonth in the previous month. This is atypical and may
be an indicator of misuse.
This customer ID submitted 20 or more payments
20PaymentsWithCustomerIDLocalMonth in the previous month. This is atypical and may
be an indicator of misuse.
This payment card submitted 20 or more
20PaymentsWithPaymentCardLocalWeek payments in the previous week. This is atypical
and may be an indicator of misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

868
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This transaction was submitted through an

anonymous web proxy, a method that is
AnonymousProxy
sometimes employed when trying to cloak one's
identity.
This transaction was submitted through an
anonymous proxy IP Address, a method that is
AnonymousProxyIP
sometimes employed when trying to cloak one's
identity.
The customer's bill-to address country does not
BINCustomerAddressGeolocationMismatch match that of the payment card's issuing bank.
This may be an indicator of a fraud attack.
This email address may have been automatically
generated by a computer. Fraudsters frequently
ComputerGeneratedEmail employ automated bots that create email
addresses programmatically to enable their fraud
attacks.
The browser used to submit this transaction has
CookiesDisabled disabled cookies. This is common to fraud
attacks and may be an indicator of misuse.
The browser used to submit this transaction has
disabled cookies and JavaScript. This is common
CookiesJavascriptDisabled
to fraud attacks and may be an indicator of
misuse.
Custom attribute 1 for this transaction is on
CustomAttribute1OnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
Custom attribute 1 for this transaction is on
CustomAttribute1OnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
Custom attribute 2 for this transaction is on
CustomAttribute2OnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
Custom attribute 2 for this transaction is on
CustomAttribute2OnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
Custom attribute 3 for this transaction is on
CustomAttribute3OnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
Custom attribute 3 for this transaction is on
CustomAttribute3OnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
Custom attribute 4 for this transaction is on
CustomAttribute4OnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

869
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

Custom attribute 4 for this transaction is on

CustomAttribute4OnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
Custom attribute 5 for this transaction is on
CustomAttribute5OnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
Custom attribute 5 for this transaction is on
CustomAttribute5OnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
The customer ID for this transaction is on
CustomerIDOnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
The customer ID for this transaction is on
CustomerIDOnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
The customer name for this transaction is on
CustomerNameOnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
The customer name for this transaction is on
CustomerNameOnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
This transaction originated from an IP address
DeviceCountriesNotAllowed located in a country on ThreatMetrix-hosted
blacklist.
The originating device is on the ThreatMetrix
DeviceIDOnThreatMetrixGlobalBlacklist
global blacklist.
The originating device was first seen across the
entire ThreatMetrix global network within the past
hour. This is uncommon and may point to a
DeviceGlobalAgeLessThanOneHour
fraudster simulating a new device through
advanced techniques in an attempt to avoid
detection.
The originating device was first seen by
Worldpay within the past hour. This may point to
DeviceLocalAgeLessThanOneHour a fraudster simulating a new device through
advanced techniques in an attempt to avoid
detection.
ThreatMetrix could not fingerprint the originating
device. This is atypical and may indicate a
DeviceNotFingerprinted
deliberate attempt by the user to cloak his or her
identity.
The originating device is on ThreatMetrix-hosted
DeviceOnLocalBlacklist
blacklist.
The originating device is on ThreatMetrix-hosted
DeviceOnLocalWhitelist
whitelist.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

870
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The originating device is on the ThreatMetrix

DeviceOnThreatMetrixGlobalBlacklist
global blacklist.
The originating device has been rejected by one
DeviceRejectedByNetwork10Times of ThreatMetrix's customers and/or partners 10
or more times on the suspicion of fraud.
The originating device has been rejected by one
DeviceRejectedByNetwork25Times of ThreatMetrix's customers and/or partners 25
or more times on the suspicion of fraud.
The originating device has been rejected by one
DeviceRejectedByNetwork5Times of ThreatMetrix's customers and/or partners 5 or
more times on the suspicion of fraud.
The originating device has been rejected by one
DeviceRejectedByNetworkInLastWeek of ThreatMetrix's customers and/or partners in
the last week on the suspicion of fraud.
The originating device has been reviewed by one
DeviceReviewedByNetwork5Times of ThreatMetrix's customers and/or partners 5 or
more times on the suspicion of fraud.
The originating device has been reviewed by one
DeviceReviewedByNetwork10Times of ThreatMetrix's customers and/or partners 10
or more times on the suspicion of fraud.
The originating device has been reviewed by one
DeviceReviewedByNetwork25Times of ThreatMetrix's customers and/or partners 25
or more times on the suspicion of fraud.
This email address has been associated with
transactions originating from locations at least
EmailDistanceTraveled
1,000 miles apart in the last hour. This is a red
flag and warrants caution.
The hostname portion (i.e. to the right of "@") of
this email address exceeds 30 characters. Email
addresses associated with suspicious domain
EmailHostnameTooLong
names are often used as part of attacks. Overly
long hostnames are a common marker of such
domains.
The hostname portion (i.e. to the right of "@") of
this email address contains non-letter characters
(e.g. numbers and special characters). Email
EmailHostnameWithNonLetters addresses associated with suspicious domain
names are often used as part of attacks.
Hostnames with non-letter characters are a
common marker of such domains.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

871
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The customer email address for this transaction

EmailOnLocalBlacklist
is on Worldpay's ThreatMetrix-hosted blacklist.
The customer email address for this transaction
EmailOnLocalWhitelist
is on Worldpay's ThreatMetrix-hosted whitelist.
This email address is on the ThreatMetrix global
EmailOnThreatMetrixGlobalBlacklist
blacklist.
The associated email address has been rejected
by one of ThreatMetrix's customers and/or
EmailRejectedByNetwork10TimesInLastDay
partners 10 or more times in the last day on the
suspicion of fraud.
A transaction using this email address has been
rejected by one of ThreatMetrix's customers
EmailRejectedByNetworkInLastWeek
and/or partners in the last week on the suspicion
of fraud.
The name portion (i.e. to the left of "@") of this
email address exceeds 30 characters. Email
addresses associated with suspicious user
EmailUsernameTooLong
names are often used as part of attacks. Overly
long user names are a common marker of such
domains.
The name portion (i.e. to the left of "@") of this
email address contains non-letter characters
(e.g. numbers and special characters). Email
EmailUsernameWithNonLetters addresses associated with suspicious usernames
are often used as part of attacks. Usernames
with non-letter characters are a common marker
of such domains.
An abnormally high number of transactions have
been submitted from this device in the last hour.
ExcessivePaymentsOnDeviceHour
This is a common indicator of fraudulent
payment.
An abnormally high number of transactions have
been submitted from this device in the last 24
ExcessivePaymentsOnDeviceDay
hours. This is a common indicator of fraudulent
payment.
An abnormally high number of transactions
appear to have been submitted from this device
ExcessivePaymentsOnFuzzyDeviceHour
in the last hour. This is a common indicator of
fraudulent payment.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

872
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

An abnormally high number of transactions

appear to have been submitted from this device
ExcessivePaymentsOnFuzzyDeviceDay
in the last 24 hours. This is a common indicator
of fraudulent payment.
The language used by the web browser used to
submit this transaction does not match the
FlashBrowserLanguageMismatch
language used by the Flash plug-in. This is
atypical and may be an indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects, cookies, and JavaScript.
FlashCook1esJavascriptDisabled
This is common to fraud attacks and may be an
indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects and cookies. This is
FlashCookiesDisabled
common to fraud attacks and may be an indicator
of misuse.
The browser used to submit this transaction has
FlashDisabled disabled Flash objects. This is common to fraud
attacks and may be an indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects, images, and cookies.
FlashImagesCookiesDisabled
This is common to fraud attacks and may be an
indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects, images, cookies, and
FlashImagesCookiesJavascriptDisabled
JavaScript. This is common to fraud attacks and
may be an indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects and images. This is
FlashImagesDisabled
common to fraud attacks and may be an indicator
of misuse.
The browser used to submit this transaction has
disabled Flash objects, images, and JavaScript.
FlashImagesJavascriptDisabled
This is common to fraud attacks and may be an
indicator of misuse.
The browser used to submit this transaction has
disabled Flash objects and JavaScript. This is
FlashJavascriptDisabled
common to fraud attacks and may be an indicator
of misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

873
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The originating device appears to have been

seen by Worldpay for the first time within the past
FuzzyDeviceLocalAgeLessThanOneHour hour. This may point to a fraudster simulating a
new device through advanced techniques in an
attempt to avoid detection.
The originating device appears to be on
FuzzyDeviceOnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
The originating device appears to be on
FuzzyDeviceOnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
The originating device appears to be on the
FuzzyDeviceOnThreatMetrixGlobalBlacklist
ThreatMetrix global blacklist.
The originating device appears to have been
rejected by one of ThreatMetrix's customers
FuzzyDeviceRejectedByNetworkInLastWeek
and/or partners in the last week on the suspicion
of fraud.
The language detected from the originating web
GeolocationLanguageMismatch browser is not appropriate for the location. This is
atypical and may be an indicator of misuse.
This transaction was submitted through a hidden
HiddenProxy web proxy, a method that is sometimes
employed when trying to cloak one's identity.
The browser used to submit this transaction has
ImagesCookiesDisabled disabled images and cookies. This is common to
fraud attacks and may be an indicator of misuse.
The browser used to submit this transaction has
disabled images, cookies, and JavaScript. This is
ImagesCookiesJavascriptDisabled
common to fraud attacks and may be an indicator
of misuse.
The browser used to submit this transaction has
ImagesDisabled disabled images. This is common to fraud attacks
and may be an indicator of misuse.
The browser used to submit this transaction has
disabled images and JavaScript. This is common
ImagesJavascriptDisabled
to fraud attacks and may be an indicator of
misuse.
The originating IP address is a potential threat
IPHasNegativeReputation based upon analysis of its activity across the
ThreatMetrix network.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

874
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The originating IP address is on

IPOnLocalBlacklist
ThreatMetrix-hosted blacklist.
The originating IP address is on
IPOnLocalWhitelist
ThreatMetrix-hosted whitelist.
The originating IP address is on the ThreatMetrix
IPOnThreatMetrixGlobalBlacklist
global blacklist.
The originating IP address has been rejected by
IPRejectedByNetwork10Times one of ThreatMetrix's customers and/or partners
10 or more times on the suspicion of fraud.
The originating IP address has been rejected by
IPRejectedByNetwork25Times one of ThreatMetrix's customers and/or partners
25 or more times on the suspicion of fraud.
The originating IP address has been rejected by
IPRejectedByNetwork5Times one of ThreatMetrix's customers and/or partners
5 or more times on the suspicion of fraud.
The browser used to submit this transaction has
JavascriptDisabled disabled JavaScript. This is common to fraud
attacks and may be an indicator of misuse.
This transaction was submitted through a known
Virtual Private Network (VPN), a method that is
KnownVPNISP
sometimes employed when trying to cloak one's
identity.
The originating device appears have to been
MalwareDetectedOnDevice
infected with malware.
This transaction was submitted through an open
OpenProxy web proxy, a method that is sometimes
employed when trying to cloak one's identity.
The customer's ship-to address country does not
PaymentCardBINShippingAddressGeolocation
match that of the payment card's issuing bank.
Mismatch
This may be an indicator of a fraud attack.
The geolocation of the True IP address does not
PaymentCardBINTrueIPGeolocationMismatch match that of the payment card's issuing bank.
This may be an indicator of a fraud attack.
This payment card has been associated with
transactions originating from locations at least
PaymentCardDistanceTraveled
1,000 miles apart in the last hour. This is a red
flag and warrants caution.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

875
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

This payment card is on the ThreatMetrix global

PaymentCardOnThreatMetrixGlobalBlacklist
blacklist.
A transaction using this payment card has been
rejected by one of ThreatMetrix's customers
PaymentCardRejectedByNetworkInLastWeek
and/or partners in the last week on the suspicion
of fraud.
The customer telephone number for this
PhoneNumberOnLocalBlacklist transaction is on Worldpay's ThreatMetrix-hosted
blacklist.
The customer telephone number for this
PhoneNumberOnLocalWhitelist transaction is on Worldpay's ThreatMetrix-hosted
whitelist.
The user appears to have cleared his or her
browser's cookies 3 or more times in the last day.
PossibleCookieWipingDay
This is common to fraud attacks and may be an
indicator of misuse.
The user appears to have cleared his or her
browser's cookies 3 or more times in the last
PossibleCookieWipingHour
hour. This is common to fraud attacks and may
be an indicator of misuse.
The user appears to have cleared his or her
browser's cookies 3 or more times in the last
PossibleCookieWipingWeek
week. This is common to fraud attacks and may
be an indicator of misuse.
This transaction may have been submitted
through a Virtual Private Network (VPN), a
PossibleVPNOrTunnel
method that is sometimes employed when trying
to cloak one's identity.
This transaction may have been submitted
through a Virtual Private Network (VPN), a
PossibleVPNConnection
method that is sometimes employed when trying
to cloak one's identity.
This transaction may have been submitted using
PotentialVirtualMachine a Virtual Machine, a method that is sometimes
employed when trying to cloak one's identity.
The originating IP proxy is a potential threat
ProxyHasNegativeReputation based upon an analysis of its activity across the
ThreatMetrix network.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

876
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The originating IP address is a potential threat

ProxyIPHasNegativeReputation based upon analysis of its activity across the
ThreatMetrix network.
The originating proxy IP address is on
ProxyIPOnLocalBlacklist
Worldpay's ThreatMetrix-hosted blacklist.
The originating proxy IP address is on
ProxyIPOnLocalWhitelist
Worldpay's ThreatMetrix-hosted whitelist.
The originating proxy IP address is on the
ProxyIPOnThreatMetrixGlobalBlacklist
ThreatMetrix global blacklist.
This transaction was submitted through a
Satellite Internet Service Provider, a method that
SatelliteISP
is sometimes employed when trying to cloak
one's identity.
This transaction was submitted through a
Satellite Proxy Internet Service Provider, a
SatelliteProxyISP
method that is sometimes employed when trying
to cloak one's identity.
Characteristics of the originating device appear
to have been modified during the course of the
SessionAnomaly
user's web session. This is atypical and may
indicate misuse.
The shipping address country does not match
that of the True IP address. This may be an
ShippingAddressTrueIPGeolocationMismatch indicator of a package
redirection/interception/forwarding or re-shipping
fraudster attack.
The characteristics of the originating browser are
consistent with common fraud attacks, and may
SuspectedSessionCloaking
be an indicator of a fraudster's deliberate attempt
to cloak his or her identity.
This transactions appears to have originated
SuspectedTORNetwork from a TOR network, a common source of fraud
attacks.
The system state of the originating device has
SystemStateAnomaly changed two or more times within the past hour.
This is atypical and may indicate misuse.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

877
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The time zone setting on the originating device

does not match to the true geolocation of the
TimeZoneTrueGeolocationMismatch
customer. This is atypical and may be an
indicator of misuse.
This transaction was submitted through a
transparent web proxy, a method that is most
TransparentProxy often used in corporate environments, though
also employed when trying to cloak one's
identity.
The geolocation of the True IP address does not
match that of the DNS provider. This may be an
TrueIPDNSGeolocationMismatch
indicator of a fraudster's attempt to cloak his or
her identity.
The originating IP address is a potential threat
TrueIPHasNegativeReputation based upon analysis of its activity across the
ThreatMetrix network.
The originating true IP address is on Worldpay's
TrueIPOnLocalBlacklist
ThreatMetrix-hosted blacklist.
The originating true IP address is on Worldpay's
TrueIPOnLocalWhitelist
ThreatMetrix-hosted whitelist.
The originating true IP address is on the
TrueIPOnThreatMetrixGlobalBlacklist
ThreatMetrix global blacklist.
The city of the True IP address does not match
that of the Proxy IP address. This may be an
TrueIPProxyIPCityMismatch
indicator of a fraudster's attempt to cloak his or
her identity.
The geolocation of the True IP address does not
match that of the Proxy IP address. This may be
TrueIPProxyIPGeolocationMismatch
an indicator of a fraudster's attempt to cloak his
or her identity.
The Internet Service Provider of the True IP
address does not match that of the Proxy IP
TrueIPProxyIPISPMismatch
address. This may be an indicator of a fraudster's
attempt to cloak his or her identity.
The organization of the True IP address does not
match that of the Proxy IP address. This may be
TrueIPProxyIPOrganizationMismatch
an indicator of a fraudster's attempt to cloak his
or her identity.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

878
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-6 Triggered Rules Definitions

Triggered Rule Name Description

The region of the True IP address does not

match that of the Proxy IP address. This may be
TrueIPProxyIPRegionMismatch
an indicator of a fraudster's attempt to cloak his
or her identity.
The originating IP address has been rejected by
one of ThreatMetrix's customers and/or partners
TrueIPRejectedByNetwork10TimesInLastDay
10 or more times in the last day on the suspicion
of fraud.
The originating true IP has been rejected by one
TrueIPRejectedByNetworkInLastWeek of ThreatMetrix's customers and/or partners in
the last week on the suspicion of fraud.
This web proxy used to submit the transaction
UnusualProxyAttributes has unusual attributes (e.g. dialup), which may
indicate an attempt to cloak one's identity.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

879
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.7 XML Validation Error Messages

Table A-7 provides examples of XML Validation Error Messages. These messages are the value
associated with the message attribute of either a cnpResponse or cnpOnlineResponse, when the
response=“1” (the response attribute).

NOTE: If response=“0”, the associated message=“Valid Format”.

For information about response values 2 through 5, please refer to Additional Response Header
Error Messages on page 882.

TABLE A-7 Response Header Error Message Examples

Example Message (message attribute of Description (line numbers will vary according
cnpOnlineResponse) to the location of the error)

Error validating xml data against the schema on The value on line 13 does not meet the minimum
line 13. The length of the value is 3, but the length requirement for the element as specified in
required minimum is 4. the schema. For example, if you specified 812 as
a value for the <expDate> element, which has a
minLength of 4, the system returns this error
message.

Error validating xml data against the schema on The value on line 18 exceeds the maximum
line 18. The length of the value is 6, but the length requirement for the element as specified in
required maximum is 4. the schema. For example, if you specified 082012
as a value for the <expDate> element, which has
a maxLength of 4, the system returns this error
message.

Error validating xml data against the schema on The value on line 11 is not a valid enumeration for
line 11. The value is not a member of the the specified element. For example, The <type>
enumeration. element allows values of VI, MC, DI, AX, DC, JC,
PP and BL. If you submitted a value of VISA, the
system returns this error message.

Error validating xml data against the schema on The <amount> element does not contains a valid
line 8. Content of element &quot;amount&quot; is value. For example, if you submitted a
incomplete. captureGivenAuth request and included the
amount element without specifying a value, the
system returns this error message.

Error validating xml data against the schema on The submitted transaction failed validation against
line 6 tag name &quot;echeckSale&quot; is not the schema, because an element name was out
allowed. Possible tag names are: of sequence or not allowed in the transaction. The
&lt;authorization&gt;,&lt;capture&gt;,&lt;credit&gt;, error message specifies the invalid element
&lt;sale&gt;,&lt;void&gt; (<echeckSale> in the example), as well as the
possible valid elements.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

880
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-7 Response Header Error Message Examples (Continued)

Example Message (message attribute of Description (line numbers will vary according
cnpOnlineResponse) to the location of the error)

System Error - Call Vantiv Typically, the system returns this error if there
was a problem with authentication due to an error
in the submitted Merchant Id, user, and/or
password.
The problem may also be due to the use of single
quotes around the attribute (merchantId) value.

Error validating xml data against the schema on The URI named in the xmlns= attribute is
line 1. Probably namespace URI of tag incorrect. The problem may also be due to the
&quot;cnpOnlineRequest&quot; is wrong (correct use of single quotes around the attribute value.
one is
Note: The URI may differ based upon the version
&quot;http://www.vantivcnp.com/schema&quot;)
of cnpAPI you are using.

Error validating xml data against the schema on The '&' symbol is used in XML to designate
line 12786. The entity name must immediately certain special characters. The error indicates that
follow the'& amp;'in the entity reference. the symbol was submitted without an entity name
(for example, &quot; or &amp;).
Typically, the error occurs when the name or one
of the address lines of the billToAddress element
includes the symbol instead of the entity
reference. For example, “John & Mary Smith”
should be sent as “John &amp; Mary Smith” or
“John and Mary Smith”).

Error validating xml data against the schema on This error is usually an indication of extraneous
line 1. Content is not allowed in prolog. characters appearing in front of the first XML
element. For example, the “?” before the
“<“symbol in the following line would cause this
error to be returned:
?<?xml version="1.0" encoding="utf-8">

Duplicate Batch (Batch ID: 28292109643, session (Batch only) The system has determined that the
sequence: 1, unique ID:) not processed - 29 Batch is a duplicate and therefore not processed.
duplicate transactions (57 total) in a row found. The first part of the message provides the count
Duplicate Batch (Batch ID: 23829210964, session of the greatest number of consecutive duplicate
sequence: 1, unique ID:) not processed - 96.49% transaction in the batch (29 in the example). The
of the transactions (57 total) in the batch are second part of the message the overall
duplicates. percentage of duplicates in the batch (96.49% in
the example).
The limits are more than 10 consecutive duplicate
transactions detected and/or more than 25% of all
transaction in the batch detected as duplicates.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

881
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.8 Additional Response Header Error Messages

When submitting transactions via Open Access, there are additional HTTP responses and validation
errors that may occur. The table below provides information about these responses/error messages, as
well as some additional errors you may encounter during Online transaction processing.

CAUTION: If you use Open Access (i.e., Transact) to submit Online transactions, you must limit the
message size to a maximum of 20K characters. We reject any transaction containing more than 20K
characters with a XML validation response value of 5.

NOTE: The response value and message in the table represent the values for the response and
message attributes of either a cnpResponse or cnpOnlineResponse.
If Resubmit? = No, you must debug and modify the submitted message prior to resubmission in
order to have any chance of success. Resubmitting the same message will result in the same
failure.

TABLE A-8 HTTP Status Message and Validation Errors

response HTTP Status

value message Code/Message Description Resubmit?

2 Invalid XML. 200 OK The submission is not valid No - debug or contact

Contact XML containing the user Worldpay Support
ecommercesupport and password elements.
@worldpay.com.

3 Invalid credentials. 200 OK The submission contains Maybe - verify

Contact empty or invalid credentials credentials
ecommercesupport (user and password).
@worldpay.com.

4 Connection limit 200 OK The merchant has Yes

exceeded. Contact exceeded the maximum
ecommercesupport number of concurrent
@worldpay.com. connections.

5 Objectionable 200 OK The system has determined Reduce the size of the
content detected. that the submission may message below the 20K
Contact contain objectionable limit and/or contact
ecommercesupport content or the message Worldpay Support
@worldpay.com. exceeds 20K maximum
characters.

N/A N/A 403 Method Not The merchant has Yes

Allowed exceeded the maximum
number of concurrent
connections.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

882
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-8 HTTP Status Message and Validation Errors

response HTTP Status

value message Code/Message Description Resubmit?

N/A N/A 405 Method Not Only HTTP POST method is No - debug or contact
Allowed allowed. Worldpay Support

N/A N/A 404 Not Found An invalid URI was used. No - debug or contact
Verify the URI you are using Worldpay Support
is correct and that you have
not appended any
parameters to the URI.

N/A N/A 417 Expectation An HTTP Expect header No - debug or contact

Failed was included in the HTTP Worldpay Support
POST, which is not allowed.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

883
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.9 ACH Return Reason Codes

Table A-9 is a list of ACH Return Reason Codes, which can apply to either Direct Debit transactions, or
Dynamic Payout funding instructions. These codes are not returned in the cnpAPI response messages,
but are visible in iQ on the Direct Debit Returns Received report, as well as the Payment Detail screen
and the Funding Instruction Detail screen.

NOTE: If an Direct Debit is returned for reason Code R01 or R09, it is eligible for redeposit.

TABLE A-9 ACH Return Reason Codes

ACH Return
Reason Code Description

R01 Insufficient funds in account

R02 Account is closed

R03 No account on file

R04 Invalid account number

R05 Unauthorized debit to consumer account

R06 Returned at request of ODFI

R07 Authorization revoked by customer

R08 Payment stopped

R09 Insufficient collected funds in account being charged

R10 Customer advises not Authorized, notice not provided, improper

source document, or amount of entry not accurately obtained from
source document

R11 Check truncation return

R12 Account sold to another financial institution

R13 Invalid ACH routing number

R14 Representative payee is deceased or cannot continue in that

capacity

R15 Beneficiary or account holder other than representative payee

deceased

R16 Account funds have been frozen

R17 Item returned because of invalid data; refer to addenda fro

information

R18 Improper effective date

R19 Amount error

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

884
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-9 ACH Return Reason Codes

ACH Return
Reason Code Description

R20 Account does not allow ACH transactions or limit for transactions
has been exceeded

R21 Invalid company identification

R22 Invalid individual ID

R23 Credit entry refused by receiver

R24 Duplicate entry

R25 Addenda record error

R26 Mandatory field error

R27 Trace number error

R28 Routing/transit number check digit error

R29 Corporate customer advised not authorized

R30 RDFI not participant in check truncation program

R31 Permissible return entry

R32 RDFI non-settlement

R33 Return of item

R34 Limited participation ODFI

R35 Return of improper debit entry

R36 Return of improper credit entry

R37 Source document presented for payment

R38 Stop payment on source document

R39 Improper source document

R40 Return of item by government agency

R41 Invalid Transaction Code

R42 Routing/transit number check digit error

R43 Invalid account number

R44 Invalid individual ID

R45 Invalid individual name or company name

R46 Invalid representative payee indicator code

R47 Duplicate enrollment

R50 State law affecting RCK acceptance

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

885
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-9 ACH Return Reason Codes

ACH Return
Reason Code Description

R51 Item is ineligible, notice not provided, signature not genuine, or

original item altered for adjustment entry

R52 Stop payment on item

R53 Item and ACH entry presented for payment

R61 Misrouted return - RDFI for original entry has placed incorrect
routing/transit number in RDFI identification field

R67 Duplicate return

R68 Untimely return - return was not sent within the established time
frame

R69 Field errors

R70 Permissible return entry not accepted

R71 Misrouted dishonored return -incorrect routing/transit number in

RDFI identification field

R72 Untimely return - dishonored return was not sent within the
established time frame

R73 Timely original return - RDFI certifies the original return entry was
sent within established time frame for original returns

R74 Corrected return - RDFI is correcting a previous return entry that

was dishonored because it contained incomplete or incorrect
information

R75 Original return not a duplicate

R76 No errors found

R80 Cross-border payment coding error

R81 Non-participant in cross-border program

R82 Invalid foreign RDFI identification

R83 Foreign RDFI unable to settle

R84 Cross-border entry not processed by originating gateway operator

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

886
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.10 ACH NoC Change Codes

Table A-10 is a list of ACH NOC Change Codes. These codes are included in the daily NOC report made
available to you via sFTP.

TABLE A-10 Direct Debit NOC Change Codes

ACH NOC
Change Code Description

C01 Incorrect account number

C02 Incorrect routing/transit number

C03 Incorrect routing/transit number and incorrect account number

C04 Incorrect account name

C05 Incorrect transaction code

C06 Incorrect account number and transaction code

C07 Incorrect routing/transit number, account number and transaction

code

C08 Incorrect foreign RDFI identification

C09 Incorrect individual ID

C13 Addenda format error

C61 Misrouted NOC

C62 Incorrect trace number

C63 Incorrect company ID

C64 Incorrect individual ID

C65 Incorrectly formatted correct data

C66 Incorrect discretionary data

C67 Routing/transit number not from original entry

C68 Account number not from original entry

C69 Incorrect transaction code

C96 Administrative return dishonor (dollar amount will be zero)

C99 Converted to MICR draft (check conversion items)

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

887
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

A.11 Canadian EFT Return Codes

Table A-11 is a list of Canadian EFT Return Reason Codes. These codes are not returned in the cnpAPI
response messages, but are visible in iQ on the Direct Debit Returns Received report, as well as the
Payment Detail screen and the Funding Instruction Detail screen.

NOTE: Return Reason Codes R901 or R908 are eligible for redeposit. Similarly, Code R900-xx are
Edit rejects, which you can resubmit with corrected information.

TABLE A-11 Canadian EFT Return Reason Codes

Canadian EFT
Return Reason Code Description

R900-07 Institution ID Invalid

R900-08 Account Number Invalid

R900-16 Institution ID for Return Invalid

R900-17 Account Number for Return Invalid

R900-D2 Destination Institute is Not Defined on FIF

R900-E1 Destination Account Number Invalid

R900-L2 Institution for Return Not Defined on FIF

R900-L3 Institution for Return Cross Reference Invalid

R900-M1 Account for Return Invalid

R901 NFS (Debit Only)

R902 Cannot Trace

R903 Payment Stopped/Recalled

R904 Post/Stale Dated

R905 Account Closed

R907 No Debit Allowed

R908 Funds Not Cleared

R909 Currency/Account Mismatch

R910 Payor/Payee Deceased

R911 Account Frozen

R912 Invalid/Incorrect Account Number

R914 Incorrect Payor/Payee Name

R915 PAD No Agreement Existed - Business/Personal

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

888
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

TABLE A-11 Canadian EFT Return Reason Codes

Canadian EFT
Return Reason Code Description

R916 PAD Not According to Agreement - Personal

R917 PAD Agreement Revoked - Personal

R918 PAD No Confirmation/Pre-Notification - Personal

R919 PAD Not According to Agreement - Business

R920 PAD Agreement Revoked - Business

R921 PAD No Confirmation/Pre-Notification - Business

R922 Customer Initiated Return - CREDIT only

R990 Institution in Default

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

889
© 2020 FIS and/or its affiliates. All rights reserved.
 Payment Transaction Response Codes

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

890
© 2020 FIS and/or its affiliates. All rights reserved.
 B
Credit Card Number Formats

This appendix has two parts. The first provides basic information about card numbers, such as length,
prefixes, and validation numbers. The second part provides information about the Luhn Mod-10 algorithm
used to validate account numbers.

Credit Card Number Formats:

Table B-1 provides information on number formats for various credit card types.

CAUTION: The data presented here is for informational proposes only and is subject to change by
the Credit Card Associations/Companies. You should verify the information using additional sources
prior to using it to create or alter any of your business systems, processes, or procedures.

TABLE B-1 Card Number Formats

Card Number Number Card Validation

Card Type Prefix/Range Length Number Length Comments

American 34 and 37 15 digits 4 digits

Express

Diners Club 36 14 digits 3 digits Submit account numbers

International starting with 36 as
Discover.

Diners Club 54 and 55 16 digits 3 digits Submit account numbers

(US and starting with 54 and 55 as
Canada) Mastercard.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

891
© 2020 FIS and/or its affiliates. All rights reserved.
 Credit Card Number Formats

Card Number Number Card Validation

Card Type Prefix/Range Length Number Length Comments

Discover 30000000-30599999 14 digits 3 digits Includes ranges for China

UnionPay, JCB, and
30950000-30959999 or
Diners Club International
35280000-35899999 16 digits supported by Discover in
36 the US.

38
39
64
65
60110000-60110999
60112000-60114999
60117400-60117499
60117700-60117999
60118600-60119999
62212600-62292599
62400000-62699999
62820000-62889999
81000000-81719999

Mastercard 51-55 16 digits 3 digits

222100 - 272099 or
19 digits

Visa 4 16 digits 3 digits

or
19 digits

Luhn Mod-10 Algorithm for Card Number Validation:

The Luhn Mod-10 algorithm was invented in 1954 by IBM scientist Hans Peter Luhn and is a relatively
simple formula used in numerous applications to validate identification numbers, including credit cards.
The algorithm detects all single digit errors in an account number, as well as most transpositions of
adjacent numbers.
Use the following method to determine if an account number is Mod-10 compliant:
1. Working from the right, double every other number. If the result of any doubling is a 2-digit number,
treat them as individual digits for step 2. For example, 2 * 9 = 18, should be treated as a 1 and an 8.
2. Add all the numbers together, including those you did not double. Remember to treat any 2-digit
numbers as individual numbers.
3. If the result of step 2 is a multiple of 10, the account number is Mod-10 compliant.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

892
© 2020 FIS and/or its affiliates. All rights reserved.
 Credit Card Number Formats

Example: Mod-10 Algorithm

For the account number 4005550000081019, the computations are shown in the table below.

4 0 0 5 5 5 0 0 0 0 0 8 1 0 1 9
x2 x2 x2 x2 x2 x2 x2 x2
8 0 0 5 10 5 0 0 0 0 0 8 2 0 2 9
8+ 0+ 0+ 5+ 1+0+ 5+ 0+ 0+ 0+ 0+ 0+ 8+ 2+ 0+ 2+ 9

The result is 40, which is a multiple of 10 and therefore compliant.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

893
© 2020 FIS and/or its affiliates. All rights reserved.
 Credit Card Number Formats

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

894
© 2020 FIS and/or its affiliates. All rights reserved.
 C
Test Card Numbers

The following table provides a list of credit card numbers you can use in our Certification environment to
construct your own transactions beyond what is required for certification. These account numbers are
extracted from the Certification tests of Chapter 2 and the transaction examples of Chapter 3. Never use
these account numbers in the live, production environment.

IMPORTANT: Per PCI DSS Requirements and Security Assessment Procedure, Section 6.4.3,
"Production data (live PANs) are not used for testing or development."

TABLE C-1 Test Card Numbers

Account Number Card Type CVV2/CID

4457010000000009 Visa 349

4457010100000008 Visa 992

4457010140000141 Visa N/A

4457010200000247 Visa N/A

4100200300011001 Visa 463

4100200300012009 Visa N/A

4100200300013007 Visa N/A

4100200310000002 Visa N/A

4024720001231239 Visa N/A

4457012400000001 Visa N/A

4457013200000001 Visa N/A

4457119922390123 Visa N/A

4457000300000007 Visa N/A

4457000100000009 Visa N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

895
© 2020 FIS and/or its affiliates. All rights reserved.
 Test Card Numbers

TABLE C-1 Test Card Numbers

Account Number Card Type CVV2/CID

4457003100000003 Visa N/A

4457000400000006 Visa N/A

4457000200000008 Visa N/A

4457000800000002 Visa N/A

4457000900000001 Visa N/A

4457001000000008 Visa N/A

4005550000081019 Visa N/A

4000000000000002 Visa 555

2223000148400010 Mastercard 001

2223000048400011 Mastercard 001

2223280062080010 Mastercard 001

2222630061560019 Mastercard 001

2222470061880012 Mastercard 001

2222400061240016 Mastercard 001

2222400041240011 Mastercard 001

2223520063560019 Mastercard 001

2223520043560014 Mastercard 001

2222420040560011 Mastercard 001

2222410040360017 Mastercard 001

2223020040760014 Mastercard 001

5112000100000003 Mastercard N/A

5112002100000009 Mastercard N/A

5112002200000008 Mastercard N/A

5112000200000002 Mastercard N/A

5112000300000001 Mastercard N/A

5112000400000000 Mastercard N/A

5112010400000009 Mastercard N/A

5112000600000008 Mastercard N/A

5112010000000003 Mastercard 261

5112010100000002 Mastercard 251

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

896
© 2020 FIS and/or its affiliates. All rights reserved.
 Test Card Numbers

TABLE C-1 Test Card Numbers

Account Number Card Type CVV2/CID

5112010140000004 Mastercard N/A

5154605300000121 Mastercard N/A

5167001020236549 Mastercard N/A

5500000254444445 Mastercard N/A

5592106621450897 Mastercard N/A

5590409551104142 Mastercard N/A

5587755665222179 Mastercard N/A

5445840176552850 Mastercard N/A

5390016478904678 Mastercard N/A

5112010201000109 Mastercard N/A

5112010202000108 Mastercard N/A

5194560012341234 Mastercard N/A

5435101234510196 Mastercard 987

5407102010000018 Mastercard N/A

5112000900000005 Mastercard N/A

6011010000000003 Discover 758

6011010100000002 Discover 184

6011010140000004 Discover N/A

8171999900000018 Discover (UnionPay) 123

8171999927660000 Discover (UnionPay) 123

375000026600004 American Express N/A

375001000000005 American Express N/A

375001010000003 American Express 0421

375001014000009 American Express N/A

341234567890127 American Express N/A

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

897
© 2020 FIS and/or its affiliates. All rights reserved.
 Test Card Numbers

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

898
© 2020 FIS and/or its affiliates. All rights reserved.
 D
PayFac Dynamic Payout

This appendix discusses the Worldpay Instruction-Based Dynamic Payout option provided for use by
Payment Facilitators and direct merchants.

NOTE: Only direct merchants with the following MCCs can use Dynamic Payout:
• 4829 (Visa and Mastercard)
• 7800 (Visa and Mastercard)
• 7801 (Visa only)
• 7802 (Visa only)

Topics covered in this document include:

• Advantages of Using Dynamic Payout
• Overview of Dynamic Payout
• Examples of Funding Instructions
• Funding Instruction Certification Testing
• SSR Reports
• Tax ID Validation Process

NOTE: Please also refer to the PayFac Dynamic Payout FAQ document, which contains answers
to numerous topics including payout timing, split platform processing, report availability, and general
process items.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

899
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.1 Advantages of Using Dynamic Payout

Dynamic Payout is a solution platform that controls the distribution of funds using flexible, customized
instructions defined by you. The solution provides a closed-loop transaction life cycle from payment to
payout. With one connection for payments and payouts, our solution reduces your dependency on other
vendors, minimizing cost associated with PCI and reducing scope.
Dynamic Payout requires you to submit instructions for each payout. You can fund merchants on a fixed
schedule, such as daily, weekly or monthly, or irregular schedule. You can even choose to delay funding
based on contractual or risk related issues.
The Dynamic Payout funding solution has the following capabilities and benefits:

Capabilities:
• Execute payouts for all card brands, including American Express, as early as the next day.
• Determine when to payout.
• Calculate the fees to charge sub-merchants for rendering service. You can use a complex formula or
a tiered billing structure. (Payment Facilitators)
• Charge fees at a transaction level.
• Maintain a reserve on your sub-merchants.
• Split across multiple bank accounts.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

900
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.2 Overview of Dynamic Payout

Dynamic Payout is a method of distributing funds to your sub-merchants/customers, physical check

(writing) services, other third party vendors (in the payment flow), and yourself via the ACH network. With
Dynamic Payout, you submit transactions normally and settled funds accumulate in an FBO (For Benefit
Of) account. You distribute the funds by submitting Batch files containing Funds Transfer Instructions (see
Examples of Funding Instructions), or Online by submitting individual instruction. You submit these
instructions based upon your payout agreements with your sub-merchants/customers (daily, weekly,
monthly, etc.). Worldpay processes the instructions and moves the funds from the holding account to the
sub-merchants/customers. Funding can take place as early as the next day after settlement or on the
same day if you utilize Same Day Funding.

FIGURE D-1 Overview of Instruction-Based Funding

Create Sub-Merchants using Portal or MP API

(Payment Facilitators only)

Submit Transactions

Payment Submit Payout Instructions using cnpAPI worldpay

Facilitator

Reconcile using Scheduled Secure Reports

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

901
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.2.1 Timing of Transactions, Reports, and Money Movement

The diagram below illustrates the typical timing and flow of transactions, reports, and money movement.
In the diagram, the process begins with the delivery of transactions on Monday morning and completes
on Wednesday morning with the final money movement.

NOTE: The diagram below does not reflect the Same Day Funding or FastAccess Funding options.
While the diagram money movement for Payment Facilitators, the timing/movement for direct
merchants is similar.

FIGURE D-2 Transaction, Reports, and Money Movement

NOTE: The money movement into the Settlement account from card and Direct Debit transactions
is the Net Settled Sales (i.e., Deposits - Refunds). The funds debited from the Operating account is
the total of Interchange + Chargebacks + Assessments + Worldpay Fees for Payment
Facilitators/merchants processing on the eComm platform or just Worldpay fees, if processing on
the Worldpay Core platform.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

902
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.2.2 Money Movement and Accounts

Figure D-3 below illustrates the various possible accounts for Payment Facilitators, as well as the funding
instructions associated with moving the funds between the accounts. Direct merchants use
customerDebit/customerCredit transaction to move money to their customers, instead of what is
shown for movement to sub-merchants. Also, direct merchants use
payoutOrgCredit/payoutOrgDebit to move fund to/from their operating account.

FIGURE D-3 Dynamic Payout Accounts

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

903
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

The cnpAPI file shown in Examples of Funding Instructions on page 908 provides examples of the
transactions used for each type of money movement. The following transaction type are available for your
use:
• Funding Instruction PayFac Credit (FIPC) - used to move funds from the PayFac Settlement
account to the PayFac Operating account.
• Funding Instruction PayFac Debit (FIPD) - used to move funds from the PayFac Operating account
to the PayFac Settlement account.
• Funding Instruction Reserve Credit (FIRC) - used to move funds from the Settlement account to
the Reserve account. Both Payment Facilitators and direct merchant can use this transaction type.
• Funding Instruction Reserve Debit (FIRD) - used to move funds from the Reserve account to the
Settlement account. Both Payment Facilitators and direct merchant can use this transaction type.
• Funding Instruction Sub-merchant Credit (FISC) - used to move funds from the PayFac
Settlement account to the sub-merchant Operating account.
• Funding Instruction Sub-merchant Debit (FISD) - used to move funds from the sub-merchant
Operating account to the PayFac Settlement account.
• Funding Instruction Vendor Credit (FIVC) - used to move funds from the Settlement account to the
Vendor account. Both Payment Facilitators and direct merchant can use this transaction type.
• Funding Instruction Vendor Debit (FIVD) - used to move funds from the Vendor account to the
Settlement account. Both Payment Facilitators and direct merchant can use this transaction type.
• Funding Instruction Physical Check Credit (FICC) - used to move funds from the Settlement
account to the Physical Check account. Both Payment Facilitators and direct merchant can use this
transaction type.
• Funding Instruction Physical Check Debit (FICD) - used to move funds from the Physical Check
account to the Settlement. Both Payment Facilitators and direct merchant can use this transaction
type.
• Funding Instruction Void - used to void a submitted, but unsettled funding instruction. (See Funding
Instruction Void Transactions on page 914.) Both Payment Facilitators and direct merchant can use
this transaction type.
• FastAccess Funding™ - used to transfer funds to certain eligible Mastercard or Visa debit cards.
Transfer of funds takes place within 30 minutes. (See FastAccess Funding on page 905.) Both
Payment Facilitators and direct merchant can use this transaction type.
• Funding Instruction Payout Org Credit - used to move funds from the merchant Settlement
account to the merchant Operating account.
• Funding Instruction Payout Org Debit - used to move funds from the merchant Operating account
to the merchant Settlement account.
• Funding Instruction Customer Credit - used to move funds from the merchant Settlement account
to the customer account.
• Funding Instruction Customer Debit - used to move funds from the customer account to the
merchant Settlement account.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

904
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.2.2.1 Same Day Funding

Starting with V11.1, Worldpay provides an additional funding instruction submission window that adds the
capability of same day funding. This means you can submit a funding instruction files (Batch or Online)
before 11:00 AM ET and the funds move the same day. Submissions must also meet the following
conditions for same day processing.
• All transactions, Batch or Online must be for less than $100,000 (single transaction limit).
• The total disbursement to any sub-merchant cannot exceed $100,000 in a single day.

NOTE: If you include a transaction over $100,000, or multiple transactions to a single entity totaling
over $100,000, we mark the transactions as same day, but processing takes place next day.
Because you set the sameDayFunding flag to true, we assess fees for same day funding. To avoid
excess fees, do not attempt to use same day funding for these transactions.

• We only process same day funding batch submissions on non-holiday weekdays (i.e., no weekends
or holidays).
• Batch or Online instructions submitted outside the allowed window are processed as next day funding
instructions.
• You must set the sameDayFunding attribute (of the batchRequest or cnpOnlineRequest) to
true.
• If you miss the submission window with a batch or online file marked for same day funding, we
process it as a normal, next day funded batch and apply only the normal next day funding fee.

D.2.2.2 FastAccess Funding

The FastAccess Funding feature allows you to fund a sub-merchant within 30 minutes of submitting the
fastAccessFunding transaction by pushing the funds to certain Mastercard or Visa cards held by your
sub-merchant.

NOTE: When pushing funds to a Mastercard, you must include the expDate and
cardValidationNum elements.

The example below uses the token structure to designate the card to which you are pushing the funds.
This transaction type also allows the use of the card structure or the paypage structure in place of the
token structure.

Example: FastAccess Funding Request (using a token)

<cnpOnlineRequest version="12.8" xmlns="http://www.vantivcnp.com/schema"
merchantId="100">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<fastAccessFunding id="A123456" reportGroup="FastPayment">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

905
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

<submerchantName>Some Merchant Inc.</submerchantName>

<fundsTransferId>123e4567e89b12d3</fundsTransferId>
<amount>3000</amount>
<disbursementType>VMD</disbursementType>
<token>
<cnpToken>1111000101039449</cnpToken>
<expDate>1112</expDate>
<cardValidationNum>987</cardValidationNum>
<type>VI</type>
</token>
</fastAccessFunding>
</cnpOnlineRequest>

Example: FastAccess Funding Response

<cnpOnlineResponse version="12.8" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<fastAccessFundingResponse id="A123456" reportGroup="Fasy Payment">
<cnpTxnId>82823972759879805</cnpTxnId>
<fundsTransferId>123e4567e89b12d3</fundsTransferId>
<response>000</response>
<responseTime>2017-09-09T20:28:32</responseTime>
<postDate>2017-09-09</postDate>
<message>Approved</message>
</fastAccessFundingResponse>
</cnpOnlineResponse>

D.2.2.3 Account Balance Verifications

When the Batch or Online transaction arrives, Worldpay performs a front-end check on each Funding
Instruction within a Batch, as well as Online instructions. We verify sufficient account balances to cover
the money movement from each account. If system detects insufficient funds in any account impacted by
a funding instruction, Worldpay rejects the individual Online instruction or the entire Batch. The returned
error message provides information about the account lacking funds. We also perform a back-end
balance check on Batch files ready for delivery upstream. In this case, if the money movement of any
Batch results in an insufficient balance in any account, we reject all Batches.

NOTE: To avoid possible account balance verification issues, Worldpay recommends you submit
debit transactions first, in a separate Session file from the credit transactions.
Also, keep in mind that the system may not handle transactions within a Batch sequentially. This is
likewise true for Batches within a Session, but we do handle Session files in the order sent. To
guarantee sequential handling of Batch files, you must submit the Batch individually in Session files.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

906
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

For example, you submit a Batch of funding instructions that include a number of reserveCredit and
reserveDebit transactions, such that the net funds movement (credits - debits) results in $200,000
being moved from the Reserve Account to the Settlement Account. If the current balance in the Reserve
account is less than $200,000, The front-end checks detect this situation and reject the entire Batch with
a reject message similar to:
<cnpResponse version="12.2" xmlns="http://www.vantivcnp.com/schema" id="691"
response="1" message="Over Balance (Cnp ID: 819812345678357001, session sequence: 2,
unique ID: null) not processed - The specified Funding Instructions would result in a
negative balance in your Reserve Account. Current settlement balance:20000000, current
reserve balance:15000000, current physical check balance:990000"
cnpSessionId="810123456789357102"></cnpResponse>

NOTE: The balance amounts shown in the example above are in cents. For example, the reserve
account balance of 15000000 is $150000.00.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

907
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.3 Examples of Funding Instructions

To use Instruction-Based Funding, you must code to cnpAPI V9.0 or above for Batch, or V11.3 or above
for Online. The example below shows a Batch containing the various funding instruction you can use. Do
not mix other transaction types in a Batch containing funding instructions.

Example: cnpAPI Funding Instructions (Payment Facilitators)

<cnpRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests="1">
<authentication>
<user>username</user>
<password>password</password>
</authentication>
<batchRequest merchantId="01601" numPayFacCredit="1" payFacCreditAmount="1000"
numPayFacDebit="1" payFacDebitAmount="2000" numSubmerchantCredit="1"
submerchantCreditAmount="3000" numSubmerchantDebit="1"
submerchantDebitAmount="4000" numReserveCredit="1" reserveCreditAmount="5000"
numReserveDebit="1" reserveDebitAmount="6000" numVendorCredit="1"
vendorCreditAmount="7000" numVendorDebit="1" vendorDebitAmount="8000"
numPhysicalCheckCredit="1" physicalCheckCreditAmount="9000"
numPhysicalCheckDebit="1" physicalCheckDebitAmount="10000"
sameDayFunding="true">
<!-- Example of PayFac funding themselves. Funds move from the PayFac Settlement
Account to the PayFac Operating Account. -->
<payFacCredit id="abc12345" reportGroup="CollectedFees">
<!-- ID of Submerchant associated with fee - NOT Payfac ID -->
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<!-- Your internal tracking number for fund transfer -->
<fundsTransferId>123e4567-e89b-12d3-a456-426655440000</fundsTransferId>
<amount>1000</amount>
</payFacCredit>
<!-- Example of PayFac returning money to the settlement account. Funds move
from the PayFac Operating Account to the PayFac Settlement Account. -->
<payFacDebit id="abc12346" reportGroup="MiscRefunds">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440001</fundsTransferId>
<amount>2000</amount>
</payFacDebit>
<!-- Example of PayFac funding the Submerchant. Funds move from the PayFac
Settlement Account to the Submerchant Account. -->
<submerchantCredit id="abc12347" reportGroup="SubMerchantPayment">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<submerchantName>Some Merchant Inc.</submerchantName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440002</fundsTransferId>
<amount>3000</amount>
<accountInfo>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

908
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
<customIdentifier>Co_Descriptor</customIdentifier>
</submerchantCredit>
<!-- Example of PayFac debiting the Submerchant. Funds move from the Submerchant
Account to the PayFac Settlement Account. -->
<submerchantDebit id="abc12348" reportGroup="SubMerchantRefund">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<submerchantName>Some Merchant Inc.</submerchantName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440003</fundsTransferId>
<amount>4000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
<customIdentifier>Co_Descriptor</customIdentifier>
</submerchantDebit>
<!-- Example of PayFac adding money into reserves. Funds move from the PayFac
Settlement Account to the Reserve Account. -->
<reserveCredit id="abc12349" reportGroup="Reserve">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440004</fundsTransferId>
<amount>5000</amount>
</reserveCredit>
<!-- Example of PayFac getting money from Reserves. Funds move from the Reserve
Account to the PayFac Settlement Account. -->
<reserveDebit id="abc12350" reportGroup="SubMerchantRefund">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440005</fundsTransferId>
<amount>6000</amount>
</reserveDebit>
<!-- Example of PayFac funding the vendor. Funds move from the PayFac Settlement
Account to the Vendor Account. -->
<vendorCredit id="abc12351" reportGroup="vendorPayment">
<fundingSubmerchantId>SomeVendor</fundingSubmerchantId>
<vendorName>Some Vendor Inc.</vendorName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440006</fundsTransferId>
<amount>7000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

909
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

</accountInfo>
</vendorCredit>
<!-- Example of PayFac debiting the vendor account. Funds move from the Vendor
Account to the Payfac Settlement Account. -->
<vendorDebit id="abc12352" reportGroup="vendorReturn">
<fundingSubmerchantId>SomeVendor</fundingSubmerchantId>
<vendorName>Some Vendor Inc.</vendorName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440007</fundsTransferId>
<amount>8000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789014</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
</vendorDebit>
<!-- Example of PayFac funding the Physical Check Account. Funds move from the
PayFac Settlement Account to the Physical Check Account -->
<physicalCheckCredit id="abc12353" reportGroup="physicalCheck">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440008</fundsTransferId>
<amount>9000</amount>
</physicalCheckCredit>
<!-- Example of PayFac debiting the Physical Check account. Funds move from the
Physical Check Account to the PayFac Settlement Account-->
<physicalCheckDebit id="abc12354" reportGroup="physicalCheckDebit">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440009</fundsTransferId>
<amount>10000</amount>
</physicalCheckDebit>
</batchRequest>
</cnpRequest>

Example: cnpAPI Funding Instructions (Direct Merchant)

<cnpRequest version="12.9" xmlns="http://www.vantivcnp.com/schema"
numBatchRequests="1">
<authentication>
<user>username</user>
<password>password</password>
</authentication>
<batchRequest merchantId="01601" numPayoutOrgCredit="1" payoutOrgAmount="1000"
numPayoutOrgDebit="1" payoutOrgAmount="2000" numCustomerCredit="1"
customerCreditAmount="3000" numCustomerDebit="1" customerDebitAmount="4000"
numReserveCredit="1" reserveCreditAmount="5000" numReserveDebit="1"
reserveDebitAmount="6000" numVendorCredit="1" vendorCreditAmount="7000"

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

910
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

numVendorDebit="1" vendorDebitAmount="8000" numPhysicalCheckCredit="1"

physicalCheckCreditAmount="9000" numPhysicalCheckDebit="1"
physicalCheckDebitAmount="10000" sameDayFunding="true">
<!-- Example of Merchant funding themselves. Funds move from the Settlement
Account to the Operating Account. -->
<payoutOrgCredit id="abc12345" reportGroup="CollectedFees">
<!-- ID of Customer associated with fee - NOT Merchant ID -->
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<!-- Your internal tracking number for fund transfer -->
<fundsTransferId>123e4567-e89b-12d3-a456-426655440000</fundsTransferId>
<amount>1000</amount>
</payFacCredit>
<!-- Example of Merchant returning money to the Settlement account. Funds move
from the Operating Account to the Settlement Account. -->
<payoutOrgDebit id="abc12346" reportGroup="MiscRefunds">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440001</fundsTransferId>
<amount>2000</amount>
</payFacDebit>
<!-- Example of Merchant funding the customer. Funds move from the Settlement
Account to the customer Account. -->
<submerchantCredit id="abc12347" reportGroup="CustomerPayment">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<customerName>John Doe</customerName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440002</fundsTransferId>
<amount>3000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
<customIdentifier>Cust_Descriptor</customIdentifier>
</submerchantCredit>
<!-- Example of Merchant debiting the customer. Funds move from the customer
Account to the Settlement Account. -->
<submerchantDebit id="abc12348" reportGroup="CustomerRefund">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<customerName>John Doe</customerName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440003</fundsTransferId>
<amount>4000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
<customIdentifier>Cust_Descriptor</customIdentifier>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

911
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

</submerchantDebit>
<!-- Example of Merchant adding money into reserves. Funds move from the
Settlement Account to the Reserve Account. -->
<reserveCredit id="abc12349" reportGroup="Reserve">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440004</fundsTransferId>
<amount>5000</amount>
</reserveCredit>
<!-- Example of Merchant getting money from Reserves. Funds move from the
Reserve Account to the Settlement Account. -->
<reserveDebit id="abc12350" reportGroup="SubMerchantRefund">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440005</fundsTransferId>
<amount>6000</amount>
</reserveDebit>
<!-- Example of Merchant funding the vendor. Funds move from the Settlement
Account to the Vendor Account. -->
<vendorCredit id="abc12351" reportGroup="vendorPayment">
<fundingCustomerId>SomeVendor</fundingCustomerId>
<vendorName>Some Vendor Inc.</vendorName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440006</fundsTransferId>
<amount>7000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
</vendorCredit>
<!-- Example of Merchant debiting the vendor account. Funds move from the Vendor
Account to the Settlement Account. -->
<vendorDebit id="abc12352" reportGroup="vendorReturn">
<fundingCustomerId>SomeVendor</fundingCustomerId>
<vendorName>Some Vendor Inc.</vendorName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440007</fundsTransferId>
<amount>8000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789014</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
</vendorDebit>
<!-- Example of Merchant funding the Physical Check Account. Funds move from the
Settlement Account to the Physical Check Account -->
<physicalCheckCredit id="abc12353" reportGroup="physicalCheck">
<fundingCustomerId>SomeCustomer</fundingCustomerId>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

912
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

<fundsTransferId>123e4567-e89b-12d3-a456-426655440008</fundsTransferId>
<amount>9000</amount>
</physicalCheckCredit>
<!-- Example of debiting the Physical Check account. Funds move from the
Physical Check Account to the Settlement Account-->
<physicalCheckDebit id="abc12354" reportGroup="physicalCheckDebit">
<fundingCustomerId>SomeCustomer</fundingCustomerId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440009</fundsTransferId>
<amount>10000</amount>
</physicalCheckDebit>
</batchRequest>
</cnpRequest>

Online Funding Instructions have the same structure as Batch transactions, except the parent element is
cnpOnlineRequest as shown in the example below.

Example: Online Sub-merchant Credit Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100" sameDayFunding="true">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<!-- Example of PayFac funding the Submerchant. Funds move from the PayFac
Settlement Account to the Submerchant Account. -->
<submerchantCredit id="A123456" reportGroup="SubMerchantPayment">
<fundingSubmerchantId>SomeSubMerchant</fundingSubmerchantId>
<submerchantName>Some Merchant Inc.</submerchantName>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440002</fundsTransferId>
<amount>3000</amount>
<accountInfo>
<accType>Checking</accType>
<accNum>123456789012</accNum>
<routingNum>114567895</routingNum>
</accountInfo>
<customIdentifier>Co_Descriptor</customIdentifier>
</submerchantCredit>
</cnpOnlineRequest>

All Funding Instruction responses, except the Void response, have the identical structure other than the
parent element. The example shown below, for a payfacCreditResponse illustrates all response
structures.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

913
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

Example: Funding Instruction Response

<payFacCreditResponse id="asdf12345" reportGroup="CollectedFees">
<cnpTnxId>82823972759879805</cnpTxnId>
<fundsTransferId>123e4567-e89b-12d3-a456-426655440000</fundsTransferId>
<response>000</response>
<responseTime>2017-09-09T20:28:32</responseTime>
<message>Approved</message>
</payFacCreditResponse>

D.3.1 Funding Instruction Void Transactions

You can use the Funding Instruction Void transaction type to void/remove a designated instruction from a
submitted batch of instructions provided the following conditions are met:
• You must be coded to XML V10.1 or above.
• Submit the Funding Instruction Void transaction prior to your cutoff time.
• You must submit the funding instruction void the same day as the funding instruction you wish to void,
or in the case of same day funding, before the intra-day cutoff times. This rule also applies to
weekends.

NOTE: When you issue a Funding Instruction Void, allow 30 minutes for the system to add the
amount of the void back to your Settlement Account.
You can not void a Fast Access Funding Instruction.

Example: Online Funding Instruction Void Request

<cnpOnlineRequest version="12.0" xmlns="http://www.vantivcnp.com/schema"
merchantId="100" sameDayFunding="false">
<authentication>
<user>User Name</user>
<password>Password</password>
</authentication>
<!-- Example of Funding Instruction Void. -->
<fundingInstructionVoid id="A123456" reportGroup="void" id="1">
<cnpTxnId>82828656962104521</cnpTxnId>
</fundingInstructionVoid>
</cnpOnlineRequest>

Example: Online Funding Instruction Void Response

<cnpOnlineResponse version="12.0" xmlns="http://www.vantivcnp.com/schema"
response="0" message="Valid Format">
<fundingInstructionVoidResponse id="1" reportGroup="void">
<cnpTxnId>82828656962109465</cnpTxnId>
<response>000</response>

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

914
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

<responseTime>2017-09-02T15:51:54</responseTime>
<message>Approved</message>
</fundingInstructionVoidResponse>
</cnpOnlineResponse>

D.4 Funding Instruction Certification Testing

In order to validate of your cnpAPI structure for Funding Instruction transaction types, submit two
Batches, one containing credit transaction and one containing debit transactions, using the data supplied
in Table D-1. To validate your Online message structure, use the supplied data to submit Online versions
of the referenced transactions.

NOTE: Although the tests separate debit and credit transactions, there are no system requirements
to do so when constructing your Batches.
For required fields without supplied data, submit any value valid for the element.

TABLE D-1 Funding Instruction Test Data

Supplied Data Elements Key Response Elements

Transaction Type Element Value Element Value

First Batch Containing Credit Transactions:

payFacCredit <fundsTransferId> 00001 <fundsTransferId> 00001

<amount> 1000 <response> 000
<message> Approved

submerchantCredit <fundsTransferId> 00003 <fundsTransferId> 00003

<amount> 3000 <response> 000
<message> Approved

reserveCredit <fundsTransferId> 00005 <fundsTransferId> 00005

<amount> 5000 <response> 000
<message> Approved

vendorCredit <fundsTransferId> 00007 <fundsTransferId> 00007

<amount> 7000 <response> 000
<message> Approved

physicalCheckCredit <fundsTransferId> 00009 <fundsTransferId> 00009

<amount> 9000 <response> 000
<message> Approved

Second Batch Containing Debit Transactions:

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

915
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

TABLE D-1 Funding Instruction Test Data

Supplied Data Elements Key Response Elements

Transaction Type Element Value Element Value

payFacDebit <fundsTransferId> 00011 <fundsTransferId> 00011

<amount> 9999999 <response> 940
<message> This Funding
Instruction results
in a negative
account balance

payFacDebit <fundsTransferId> 00002 <fundsTransferId> 00002

<amount> 2000 <response> 000
<message> Approved

submerchantDebit <fundsTransferId> 00004 <fundsTransferId> 00004

<amount> 4000 <response> 000
<message> Approved

reserveDebit <fundsTransferId> 00006 <fundsTransferId> 00006

<amount> 6000 <response> 000
<message> Approved

vendorDebit <fundsTransferId> 00008 <fundsTransferId> 00008

<amount> 8000 <response> 000
<message> Approved

physicalCheckDebit <fundsTransferId> 00010 <fundsTransferId> 00010

<amount> 10000 <response> 000
<message> Approved

To test the CTX Information functionality, you must introduce the transactions below in Batch format.
Although the tests transactions specified are submerchantCredit transactions, you can use the same
data to test submerchantDebit, vendorCredit, and vendorDebit transactions.

NOTE: For the approved test below, your Implementation Consultant verifies the receipt of the
ctxPaymentDetail elements included in the transaction.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

916
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

TABLE D-2 CTX Information Test Data

Supplied Data Elements Key Response Elements

Transaction Type Element Value Element Value

submerchantCredit <fundsTransferId> 01003 <fundsTransferId> 01003

<amount> 5000 <response> 000
<ctxPaymentDetail> Include this element <message> Approved
ten (10) times.

submerchantCredit <fundsTransferId> 01004 Returns an XML

Validation error.
<amount> 5000
<ctxPaymentDetail> Use a value in
excess of 80
characters.

TABLE D-3 FastAccess Funding Instruction Test Data

Supplied Data Elements Key Response Elements

OrderId Element Value Element Value

fastAccessFunding <type> VI <response> 000

<number> 4005554444444403 <message> Approved
<amount> 10000

fastAccessFunding <type> VI <response> 000

<number> 4005554444444403 <message> Approved
<amount> 000

fastAccessFunding <type> MC <response> 000

<number> 5413330089020011 <message> Approved
<amount> 17500

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

917
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.5 SSR Reports

You are required to receive the following Scheduled Secure Reports when using the Dynamic Payout
feature:
• Funding Reject Report by ACH Return Date - contains data about failures to transfers funds to
Sub-merchants accounts. The report is produced daily.
• NoC Report by ACH Return Date - contains NoC data detailing changes in Sub-merchants accounts
discovered during funds transfer operations. The report is produced daily.
• Account Balance Report- contains data about balances in various accounts used by this solution.
The report is produced daily, each hour between 1:00PM ET and 9:00PM ET.
• Tax Id Mismatch Report (same as above) - contains data about Legal Entity Tax Identification
Numbers validation failures. The report is produced daily.
• Funding Instruction Confirmation Report - provides data about all settled funding instructions from
the previous day.
• Balance Summary Report - provides a summary of the balance in the PayFac account for the
previous day.
In addition to the required reports listed above, you can use the SSR to track transactional data,
chargebacks, and to assist in reconciliation operations. Some of these reports are:
• Net Settled Sales by Transaction Report - includes all settled and conveyed transactions (deposits
and refunds), including Direct Debit transactions. The report can be scheduled based upon either
Activity (post) or Settlement (funds transfer) day.
• Session Report - includes all transactions for a particular activity post day and allows reconciliation
against submitted transactions.
• Transaction Summary Report - includes summarized deposits and refunds (both settled and
conveyed) submitted by the merchant and broken down by purchase currency, reporting groups, and
payment type for a particular activity post day.
• Activity Report - includes summarized financial data for transactions (deposits and refunds) based
upon activity post date and broken down by Reporting Group and payment type.
• Settlement Report - includes summarized financial data for settled transactions (deposits and
refunds) based upon settlement (funds transfer) date and broken down by Reporting Group and
payment type.
• Chargeback Financial Report - includes detailed information about financial impacting chargeback
activities for a given activity (post) or fund transfer (settlement) date.
• Chargeback Status Report - provides details of all chargeback activities for a designated activity
(post day) date or date range in the case of a monthly report. This report is run daily or monthly.
• Fee Report - provides a detailed breakdown of all Worldpay and Passthrough (Interchange) fees
associated with transactions for a given activity (post) or fund transfer (settlement) date.
• Visa Fixed Acquirer Network Fee Report - a PayFac report that provides details of Visa FANF fees
assessed (by Legal Entity). Worldpay produces the report on the 8th of each month. Each report
contains data for the prior month.
• Mastercard per Location Fee Report - a PayFac report that provides details of location fees
assessed by Legal Entity and Sub-merchant. Worldpay produces the report on the 15th of each
month. Each report contains data for the prior month.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

918
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

NOTE: For additional information about these and other reports, please refer to the latest version of
the Worldpay eComm Scheduled Secure Reports Reference Guide.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

919
© 2020 FIS and/or its affiliates. All rights reserved.
 PayFac Dynamic Payout

D.6 Tax ID Validation Process

The Internal Revenue Service requires that “a payment settlement entity (PSE) must file Form 1099-K,
Payment Card and Third Party Network Transactions, for payments made in settlement of reportable
payment transactions for each calendar year.”
Worldpay issues 1099-Ks to e-commerce merchants, Payment Facilitators, and sub-merchants who are
enabled for Dynamic Payout. Prior to issuing 1099-Ks, it is the responsibility of the Payment Facilitator to
provide and validate sub-merchant Tax ID information to ensure that the validation process performed by
Worldpay through IRS.gov is successful.
If the Tax ID validation fails, it is indicated in the Legal Entity Background Check Results panel of the
PayFac Portal. You can also view the PayFac Tax Id Validation Report, available through the
Scheduled Secure Report (SSR) service, to determine if a Legal Entity Tax ID Validation has failed. This
report only applies to legal entities that have a sub-merchant funded through our platform, and is
produced daily.
You can re-submit the sub-merchant request when certain Tax ID validation errors occur using the Edit
button at the top of the View Sub-merchant page of the PayFac Portal to edit and re-submit Tax ID
information.

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

920
© 2020 FIS and/or its affiliates. All rights reserved.
 Index
Numerics applicationExpirationDate, 360
applicationPrimaryAccountNumber, 361
3DS response certification testing, 136 approvedAmount, 362
authAmount, 363
A authCode, 364
authDate, 365
AAVS Response Codes, 860 authenticatedByMerchant, 366
accNum, 324 authentication, 367
Account Updater, 14 authenticationResult, 369
accountInfo, 325 authenticationTransactionId, 370
accountInformation, 326 authenticationValue, 371
accountNumber, 328 authInformation, 372
accountNumberLength, 329 authorization, 373
accountPasshash, 330 Authorization lifespan, 198
accountRangeId, 331 American Express, 69
accountUpdate, 332 Discover, 69
accountUpdateFileRequestData, 333 Mastercard, 69
accountUpdater, 334 PayPal, 69
accountUpdateResponse, 338 Visa, 69
accountUpdateSource, 339 Authorization Reversal transactions
accType, 340 certification testing, 106
actionReason, 341 authorizationResponse, 374
activate, 342 authReversal, 375
activateResponse, 343 authReversalResponse, 376
activateReversal, 344 availableBalance, 377
activateReversalResponse, 345 AVS Filtering, 31
active, 346 AVS response code testing, 129
addOnCode, 347 AVS Response Codes, 859
address response certification testing, 130 avsResult, 378
addressLine1, 348
Advanced AVS Response Codes, 860
B
advancedAVSResult, 349
advancedFraudChecks, 350 balanceInquiry, 379
advancedFraudResults, 351 balanceInquiryResponse, 380
affiliate, 352 Basic Fraud Tools
affluence, 353 AVS Filtering, 31
Affluence Indicator Feature, 25 Fraud Velocity Filtering, 30
allowPartialAuth, 354 Prepaid Card Filtering, 29
American Express Prior Chargeback Filtering, 30
Authorization lifespan, 198 Prior Fraud Filtering, 31
amount, 355 Security Code No-match Filtering, 30
androidpayResponse, 356 Basic Fraud tools
applepay, 357 International Card Filtering, 29
applepayResponse, 358 batchRequest, 381
applicationData, 359 batchResponse, 390

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

921
© 2020 FIS and/or its affiliates. All rights reserved.
 Index

beginningBalance, 391 cnpToken, 434

billingDate, 392 cnpTxnId, 435
billToAddress, 393 code, 436
bin, 395 commodityCode, 437
bypassVelocityCheck, 396 companyName, 438
country, 439
C createAddOn, 440
createDiscount, 441
campaign, 397 createPlan, 442
cancelSubscription, 398 createPlanResponse, 443
cancelSubscriptionResponse, 398, 399 credit, 444
capability, 400 creditCnpTxnId, 446
capture, 401 creditResponse, 447
captureGivenAuth, 403 cryptogram, 448
captureGivenAuthResponse, 404 ctxPaymentDetail, 466
captureResponse, 405 ctxPaymentInformation, 467
card, 406 currencyCode, 449
cardAcceptorTaxId, 408 customAttribute1, 450
Cardholder Type Indicator Feature, 26 customBilling, 451
cardholderAuthentication, 409 customerInfo, 458
cardholderId, 410 customerIpAddress, 459
cardholderName, 411 customerReference, 461
cardOrToken, 412 customerRegistrationDate, 462
cardProductType, 413 customerType, 464
cardSuffix, 414 customerWorkTelephone, 465
cardValidationNum, 415 customIdentifier, 453
cardValidationResult, 416
cashBackAmount, 417 D
catLevel, 418
ccdPaymentInformation, 419 data, 468
certification testing deactivate, 469
3DS responses, 136 deactivateResponse, 470
address responses, 130 deactivateReversal, 471
Authorization Reversal transactions, 106 deactivateReversalResponse, 472
AVS response codes, 129 debitNetworkName, 473
response codes and messages, 133 debtRepayment, 474
volume testing, 189 Decline Notice
chargeback, 420 eCheck Verification, 47
checkNum, 422 deleteAddOn, 475
checkoutId, 424 deleteDiscount, 476
city, 425 deliveryType, 477
clinicOtherAmount, 426 dentalAmount, 478
cnpInternalRecurringRequest, 427 depositReversal, 479
cnpOnlineRequest, 428 depositReversalResponse, 480
cnpOnlineResponse, 429 description, 481
cnpRequest, 431 descriptor, 482
cnpResponse, 432 destinationCountryCode, 483
cnpSessionId, 433 destinationPostalCode, 484

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

922 © 2020 FIS and/or its affiliates. All rights reserved.
 Index

detailTax, 485 echeckVoid, 512

deviceManufacturerIdentifier, 486 echeckVoidResponse, 513
deviceReputationScore, 487 eciIndicator, 514
deviceReviewStatus, 488 email, 515
disbursementType, 489 employerName, 516
discountAmount, 491 encryptedAccountNumber, 517
discountCode, 492 encryptedCardValidationNum, 518
Discover encryptedTrack, 519
Authorization lifespan, 198 encryptionKeyId, 520
dob, 493 endDate, 521
Duplicate Transaction Detection Feature, 8 endingBalance, 522
dutyAmount, 495 endpoint, 523
Dynamic Payout enhancedAuthResponse, 524
Account Balance Verification, 906 enhancedData, 526
Certification Testing, 915 entryMode, 530
FastAccess Funding, 905 ephemeralPublicKey, 531
Funding Instruction Void, 914 error messages
Funding Instructions, 908 response Header, 882
Money Movement and Accounts, 903 XML validation, 880
Overview, 901 expDate, 533
Same Day Funding, 905 expMonth, 534
Tax Id Validation, 920 expYear, 535
extendedCardResponse, 536
E
F
echeck, 496
eCheck Auto Redeposit Feature, 49 FastAccess Funding, 905
eCheck NoC Update Feature, 48 fastAccessFunding, 537
eCheck Processing Feature, 47 fastAccessFundingResponse, 538
eCheck Validation Feature, 47 Features
eCheck Verification Account Updater, 14
Decline Notice, 47 Affluence Indicator, 25
eCheck Verification Feature, 47 Cardholder Type Indicator, 26
eCheckAccountSuffix, 497 Duplicate Transaction Detection, 8
echeckCredit, 498 eCheck Auto Redeposit, 49
echeckCreditResponse, 499 eCheck NoC Update, 48
echeckForToken, 500 eCheck Processing, 47
echeckPreNoteCredit, 501 eCheck Validation, 47
echeckPreNoteCreditResponse, 502 eCheck Verification, 47
echeckPreNoteSale, 503 Issuer Country Indicator, 25
echeckPreNoteSaleResponse, 504 Prepaid Indicator, 24
echeckRedeposit, 505 Recovery, 12
echeckRedepositResponse, 506 Recurring Engine, 18
echeckSale, 507 Recycling Engine, 12
echeckSalesResponse, 508 Report Groups, 10
echeckToken, 509 Tokenization, 38
echeckVerification, 510 fieldValue, 539
echeckVerificationResponse, 511 filtering, 540

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

923
© 2020 FIS and/or its affiliates. All rights reserved.
 Index

Filtering Rules, 32 itemDescription, 581

finalPayment, 541 itemDiscountAmount, 582
firstName, 543 itemSequenceNumber, 583
forceCapture, 544
forceCaptureResponse, 545 K
formatId, 546
Fraud Check transaction, 36 ksn, 584
Fraud Filtering
Filtering Rules, 32 L
Fraud Toolkit, 28
Fraud Velocity Filtering, 30 lastName, 585
fraudCheck, 547, 731 lineItemData, 586
fraudCheckResponse, 548 lineItemTotal, 588
fraudFilterOverride, 549 lineItemTotalWithTax, 589
fraudResult, 550 load, 590
Funding Instruction Void, 914 loadResponse, 591
Funding Instructions, 908 loadReversal, 592
fundingInstructionVoid, 552 loadReversalResponse, 593
fundingInstructionVoidResponse, 553
fundingSource, 554 M
fundingSubmerchantId, 555
mandateProvider, 598
fundsTransferId, 556
mandateReference, 599
mandateSignatureDate, 600
G mandateUrl, 601
giftCardBin, 559 Mastercard
giftCardResponse, 564 Authorization lifespan, 198
merchantData, 604
merchantGroupingId, 605
H
merchantId, 606
header, 567 message, 607
healthcareIIAS, 569 middleInitial, 608
mpos, 609
I
N
iban, 571
idle time timeout, 92 name, 610
IIASFlag, 574 networkField, 612
incomeAmount, 575 networkName, 614
incomeCurrency, 576 networkResponse, 615
Instruction-Based Dynamic Payout, 79 networkSubField, 616
international, 577 networkTransactionId, 617
International Card Filtering, 29 newAccountInfo, 618
intervalType, 578 newCardInfo, 619
invoiceReferenceNumber, 579 newCardTokenInfo, 620
Issuer Country Indicator Feature, 25 newTokenInfo, 621
Issuer Insights, 24 nextRecycleTime, 622
issuerCountry, 580 number, 624

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

924 © 2020 FIS and/or its affiliates. All rights reserved.
 Index

numberOfPayments, 625 physicalCheckDebit, 669

physicalCheckDebitResponse, 670
O pin, 671
pinlessDebitRequest, 672
onlinePaymentCryptogram, 626 pinlessDebitResponse, 673
optional certification tests planCode, 674
3DS responses, 136 pos, 675
address responses, 130 postDate, 676
AVS response codes, 129 postDay, 677
response codes and messages, 133 preferredLanguage, 679
volume testing, 189 prepaid, 680
orderDate, 627 Prepaid Card Filtering, 29
orderId, 628 Prepaid Indicator Feature, 24
orderSource, 629 prepaidCardType, 681
origAccountNumber, 632 Prior Chargeback Filtering, 30
origActionType, 633 Prior Fraud Filtering, 31
origCnpTxnId, 634 processingInstructions, 682
origId, 635 processingType, 683
originalAccountInfo, 631 productCode, 685
originalCard, 637 publicKeyHash, 688
originalCardInfo, 638
originalCardTokenInfo, 639 Q
originalNetworkTransactionId, 640
originalToken, 644 quantity, 689
originalTokenInfo, 645 Query Transaction, 77, 286
originalTransactionAmount, 646 queryTransaction, 690
queryTransactionResponse, 691
P queryTransactionUnavailableResponse, 692

password, 648 R
payerId, 649
payFacCredit, 650, 657 Recovery, 12
payFacCreditResponse, 651, 658 Recurring Engine, 18
payFacDebit, 652, 659 recurringRequest, 693
payFacDebitResponse, 653, 660 recurringResponse, 693, 694
paymentAccountReferenceNumber, 654 recurringTxnId, 695
paymentDataType, 655 recycleAdvice, 696
paypage, 661 recycleAdviceEnd, 697
paypageRegistrationId, 662 recycleBy, 698
PayPal recycleEngineActive, 699
Authorization lifespan, 198 recycleId, 700
paypal, 663 recycling, 701
payPalNotes, 664 Recycling Engine, 12
payPalOrderComplete, 665 Recycling Engine and Auth Reversal, 71, 78
persistent connection timeout, 92 recyclingRequest, 703
phone, 666 redirectToken, 704
physicalCheckCredit, 667 redirectUrl, 705
physicalCheckCreditResponse, 668 refundReversal, 707

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

925
© 2020 FIS and/or its affiliates. All rights reserved.
 Index

refundReversalResponse, 708 submerchantName, 754

registerTokenRequest, 709 subscription, 755
registerTokenResponse, 710 subscriptionId, 757
reloadable, 711 surchargeAmount, 758
Report Group Feature, 10
reserveCredit, 712 T
reserveCreditResponse, 713
reserveDebit, 714 Tagging Transactions, 11
reserveDebitResponse, 715 taxAmount, 760
residenceStatus, 716 taxExempt, 761
response, 717 taxIncludedInTotal, 762
response codes and messages testing, 133 taxRate, 763
Response Header error messages, 882 taxType, 764
responseCode, 718 taxTypeIdentifier, 765
responseMessage, 719 terminalId, 766
responseTime, 720 testing
results_Max10, 721 Authorization Reversal transactions, 106
RFRRequest, 724 optional certification tests
RFRResponse, 725 3DS responses, 136
routingNum, 728 address responses, 130
routingPreference, 729 AVS response codes, 129
RxAmount, 730 response codes and messages, 133
volume testing, 189
S threatMetrixSessionId, 767
timeout
sale, 731 persistent connection, 92
saleResponse, 732 Timeout settings, 91
salesTax, 733 token, 768
Same Day Funding, 905 Tokenization Feature, 38
secondaryAmount, 734 tokenMessage, 770
Security Code No-match Filtering, 30 tokenResponse, 771
sepaDirectDebit, 735 tokenResponseCode, 772
sepaDirectDebitResponse, 736 totalHealthcareAmount, 774
sequenceType, 738 track, 775
shipFromPostalCode, 739 track1Status, 776
shippingAmount, 740 track2Status, 777
shipToAddress, 741 transactionAmount, 778
signature, 743 transactionId, 779
skipRealtimeAU, 744 translateToLowValueTokenRequest, 780
ssn, 747 translateToLowValueTokenResponse, 781
startDate, 748 trialIntervalType, 782
state, 749 trialNumberOfIntervals, 783
Status Query Transaction, 77, 286 triggeredRule, 784
stopping auto-recycling, 71, 78 type, 786
submerchantCredit, 454, 750
submerchantCreditResponse, 455, 751 U
submerchantDebit, 456, 752
submerchantDebitResponse, 457, 753 unitCost, 788

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

926 © 2020 FIS and/or its affiliates. All rights reserved.
 Index

unitOfMeasure, 789 X
unload, 790
unloadResponse, 791 XML elements
unloadReversal, 792 accNum, 324
unloadReversalResponse, 793 accountInfo, 325
updateAddOn, 794 accountInformation, 326
updateCardValidationNumOnToken, 796 accountNumber, 328
updateCardValidationNumOnTokenResponse, accountNumberLength, 329
797 accountPasshash, 330
updatedCard, 795 accountRangeId, 331
updateDiscount, 798 accountUpdate, 332
updatedToken, 806 accountUpdateFileRequestData, 333
updatePlan, 799 accountUpdater, 334
updatePlanResponse, 800 accountUpdateResponse, 338
updateSubscription, 801 accountUpdateSource, 339
updateSubscriptionResponse, 805 accType, 340
url, 807 actionReason, 341
user, 808 activate, 342
activateResponse, 343
V activateReversal, 344
activateReversalResponse, 345
Value Added Services active, 346
Fraud Toolkit, 28 addOnCode, 347
Issuer Insights, 24 addressLine1, 348
vendorCredit, 809 advancedAVSResult, 349
vendorCreditResponse, 810 advancedFraudChecks, 350
vendorDebit, 811 advancedFraudResults, 351
vendorDebitResponse, 812 affiliate, 352
vendorName, 813 affluence, 353
verificationCode, 814 allowPartialAuth, 354
verify, 815 amount, 355
version, 816 androidpayResponse, 356
virtualAccountNumber, 817 applepay, 357
virtualGiftCard, 818 applepayResponse, 358
virtualGiftCardBin, 819 applicationData, 359
virtualGiftCardResponse, 820 applicationExpirationDate, 360
Visa applicationPrimaryAccountNumber, 361
Authorization lifespan, 198 approvedAmount, 362
visionAmount, 821 authAmount, 363
void, 822 authCode, 364
voidResponse, 823 authDate, 365
volume certification testing, 189 authenticatedByMerchant, 366
authentication, 367
W authenticationResult, 369
authenticationTransactionId, 370
wallet, 824 authenticationValue, 371
walletSourceType, 825 authInformation, 372
walletSourceTypeId, 826 authorization, 373

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

927
© 2020 FIS and/or its affiliates. All rights reserved.
 Index

authorizationResponse, 374 code, 436

authReversal, 375 commodityCode, 437
authReversalResponse, 376 companyName, 438
availableBalance, 377 country, 439
avsResult, 378 createAddOn, 440
balanceInquiry, 379 createDiscount, 441
balanceInquiryResponse, 380 createPlan, 442
batchRequest, 381 createPlanResponse, 443
batchResponse, 390 credit, 444
beginningBalance, 391 creditCnpTxnId, 446
billingDate, 392 creditResponse, 447
billToAddress, 393 cryptogram, 448
bin, 395 ctxPaymentDetail, 466
bypassVelocityCheck, 396 ctxPaymentInformation, 467
campaign, 397 currencyCode, 449
cancelSubscription, 398 customAttribute1, 450
cancelSubscriptionResponse, 398, 399 customBilling, 451
capability, 400 customerInfo, 458
capture, 401 customerIpAddress, 459
captureGivenAuth, 403 customerReference, 461
captureGivenAuthResponse, 404 customerRegistrationDate, 462
captureResponse, 405 customerType, 464
card, 406 customerWorkTelephone, 465
cardAcceptorTaxId, 408 customIdentifier, 453
cardholderAuthentication, 409 data, 468
cardholderId, 410 deactivate, 469
cardholderName, 411 deactivateResponse, 470
cardOrToken, 412 deactivateReversal, 471
cardProductType, 413 deactivateReversalResponse, 472
cardSuffix, 414 debitNetworkName, 473
cardValidationNum, 415 debtRepayment, 474
cardValidationResult, 416 deleteAddOn, 475
cashBackAmount, 417 deleteDiscount, 476
catLevel, 418 deliveryType, 477
ccdPaymentInformation, 419 dentalAmount, 478
chargeback, 420 depositReversal, 479
checkNum, 422 depositReversalResponse, 480
checkoutId, 424 description, 481
city, 425 descriptor, 482
clinicOtherAmount, 426 destinationCountryCode, 483
cnpInternalRecurringRequest, 427 destinationPostalCode, 484
cnpOnlineRequest, 428 detailTax, 485
cnpOnlineResponse, 429 deviceManufacturerIdentifier, 486
cnpRequest, 431 deviceReputationScore, 487
cnpResponse, 432 deviceReviewStatus, 488
cnpSessionId, 433 disbursementType, 489
cnpToken, 434 discountAmount, 491
cnpTxnId, 435 discountCode, 492

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

928 © 2020 FIS and/or its affiliates. All rights reserved.
 Index

dob, 493 fraudCheck, 547, 731

dutyAmount, 495 fraudCheckResponse, 548
echeck, 496 fraudFilterOverride, 549
eCheckAccountSuffix, 497 fraudResult, 550
echeckCredit, 498 fundingInstructionVoid, 552
echeckCreditResponse, 499 fundingInstructionVoidResponse, 553
echeckForToken, 500 fundingSource, 554
echeckPreNoteCredit, 501 fundingSubmerchantId, 555
echeckPreNoteCreditResponse, 502 fundsTransferId, 556
echeckPreNoteSale, 503 giftCardBin, 559
echeckPreNoteSaleResponse, 504 giftCardResponse, 564
echeckRedeposit, 505 header, 567
echeckRedepositResponse, 506 healthcareIIAS, 569
echeckSale, 507 iban, 571
echeckSalesResponse, 508 IIASFlag, 574
echeckToken, 509 incomeAmount, 575
echeckVerification, 510 incomeCurrency, 576
echeckVerificationResponse, 511 international, 577
echeckVoid, 512 intervalType, 578
echeckVoidResponse, 513 invoiceReferenceNumber, 579
eciIndicator, 514 issuerCountry, 580
email, 515 itemDescription, 581
employerName, 516 itemDiscountAmount, 582
encryptedAccountNumber, 517 itemSequenceNumber, 583
encryptedCardValidationNum, 518 ksn, 584
encryptedTrack, 519 lastName, 585
encryptionKeyId, 520 lineItemData, 586
endDate, 521 lineItemTotal, 588
endingBalance, 522 lineItemTotalWithTax, 589
endpoint, 523 load, 590
enhancedAuthResponse, 524 loadResponse, 591
enhancedData, 526 loadReversal, 592
entryMode, 530 loadReversalResponse, 593
ephemeralPublicKey, 531 mandateProvider, 598
expDate, 533 mandateReference, 599
expMonth, 534 mandateSignatureDate, 600
expYear, 535 mandateUrl, 601
extendedCardResponse, 536 merchantData, 604
fastAccessFunding, 537 merchantGroupingId, 605
fastAccessFundingResponse, 538 merchantId, 606
fieldValue, 539 message, 607
filtering, 540 middleInitial, 608
finalPayment, 541 mpos, 609
firstName, 543 name, 610
forceCapture, 544 networkField, 612
forceCaptureResponse, 545 networkName, 614
formatId, 546 networkResponse, 615

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

929
© 2020 FIS and/or its affiliates. All rights reserved.
 Index

networkSubField, 616 postDate, 676

networkTransactionId, 617 postDay, 677
newAccountInfo, 618 preferredLanguage, 679
newCardInfo, 619 prepaid, 680
newCardTokenInfo, 620 prepaidCardType, 681
newTokenInfo, 621 processingInstructions, 682
nextRecycleTime, 622 processingType, 683
number, 624 productCode, 685
numberOfPayments, 625 publicKeyHash, 688
onlinePaymentCryptogram, 626 quantity, 689
orderDate, 627 queryTransaction, 690
orderId, 628 queryTransactionResponse, 691
orderSource, 629 queryTransactionUnavailableResponse, 692
origAccountNumber, 632 recurringRequest, 693
origActionType, 633 recurringResponse, 693, 694
origCnpTxnId, 634 recurringTxnId, 695
origId, 635 recycleAdvice, 696
originalAccountInfo, 631 recycleAdviceEnd, 697
originalCard, 637 recycleBy, 698
originalCardInfo, 638 recycleEngineActive, 699
originalCardTokenInfo, 639 recycleId, 700
originalNetworkTransactionId, 640 recycling, 701
originalToken, 644 recyclingRequest, 703
originalTokenInfo, 645 redirectToken, 704
originalTransactionAmount, 646 redirectUrl, 705
password, 648 refundReversal, 707
payerId, 649 refundReversalResponse, 708
payFacCredit, 650, 657 registerTokenRequest, 709
payFacCreditResponse, 651, 658 registerTokenResponse, 710
payFacDebit, 652, 659 reloadable, 711
payFacDebitResponse, 653, 660 reserveCredit, 712
paymentAccountReferenceNumber, 654 reserveCreditResponse, 713
paymentDataType, 655 reserveDebit, 714
paypage, 661 reserveDebitResponse, 715
paypageRegistrationId, 662 residenceStatus, 716
paypal, 663 response, 717
payPalNotes, 664 responseCode, 718
payPalOrderComplete, 665 responseMessage, 719
phone, 666 responseTime, 720
physicalCheckCredit, 667 results_Max10, 721
physicalCheckCreditResponse, 668 RFRRequest, 724
physicalCheckDebit, 669 RFRResponse, 725
physicalCheckDebitResponse, 670 routingNum, 728
pin, 671 routingPreference, 729
pinlessDebitRequest, 672 RxAmount, 730
pinlessDebitResponse, 673 sale, 731
planCode, 674 saleResponse, 732
pos, 675 salesTax, 733

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

930 © 2020 FIS and/or its affiliates. All rights reserved.
 Index

secondaryAmount, 734 unloadResponse, 791

sepaDirectDebit, 735 unloadReversal, 792
sepaDirectDebitResponse, 736 unloadReversalResponse, 793
sequenceType, 738 updateAddOn, 794
shipFromPostalCode, 739 updateCardValidationNumOnToken, 796
shippingAmount, 740 updateCardValidationNumOnTokenResponse
shipToAddress, 741 , 797
signature, 743 updatedCard, 795
skipRealtimeAU, 744 updateDiscount, 798
ssn, 747 updatedToken, 806
startDate, 748 updatePlan, 799
state, 749 updatePlanResponse, 800
submerchantCredit, 454, 750 updateSubscription, 801
submerchantCreditResponse, 455, 751 updateSubscriptionResponse, 805
submerchantDebit, 456, 752 url, 807
submerchantDebitResponse, 457, 753 user, 808
submerchantName, 754 vendorCredit, 809
subscription, 755 vendorCreditResponse, 810
subscriptionId, 757 vendorDebit, 811
surchargeAmount, 758 vendorDebitResponse, 812
taxAmount, 760 vendorName, 813
taxExempt, 761 verificationCode, 814
taxIncludedInTotal, 762 verify, 815
taxRate, 763 version, 816
taxType, 764 virtualAccountNumber, 817
taxTypeIdentifier, 765 virtualGiftCard, 818
terminalId, 766 virtualGiftCardBin, 819
threatMetrixSessionId, 767 virtualGiftCardResponse, 820
token, 768 visionAmount, 821
tokenMessage, 770 void, 822
tokenResponse, 771 voidResponse, 823
tokenResponseCode, 772 wallet, 824
totalHealthcareAmount, 774 walletSourceType, 825
track, 775 walletSourceTypeId, 826
track1Status, 776 yearsAtEmployer, 828
track2Status, 777 yearsAtResidence, 829
transactionAmount, 778 zip, 830
transactionId, 779
translateToLowValueTokenRequest, 780 Y
translateToLowValueTokenResponse, 781
trialIntervalType, 782 yearsAtEmployer, 828
trialNumberOfIntervals, 783 yearsAtResidence, 829
triggeredRule, 784
type, 786 Z
unitCost, 788
unitOfMeasure, 789 zip, 830
unload, 790

eComm cnpAPI Reference Guide V2.18 • API Release: 12.13

931
© 2020 FIS and/or its affiliates. All rights reserved.