Home

Orbital_Gateway_Inte..

Contents

1. December 2006 Code Definition Status Action Pre noted Approved None 28 29 o N Received and stored Approved None ITO S UY zd ix X Merchant not MC SecureCode Enabled Call Fol 59 Do Not Honor Low Fraud Cust F ecline Blanks not passed in Reserved Field Fix cline Orbital Gateway Interface Specification Page 125 Code Definition Status Action ad X a X Doesnot match MOP a X a X Invalid Institution Code a X Invalid Expiration Date Decline Cust Invalid Amount a ITO ITO a X e Method of Payment is Invalid for Merchant z E E di X a X Missing Companion Data Invalid Merchant a X E 200 wo 87 a a X a a X a X a X December 2006 Orbital Gateway Interface Specification Page 126 Code Definition Action Status Payments Not Total Order Fix Bad Order Number Fix mor mor FPO Locked Eror Wait FPO Not Allowed Eror Call Auth Amount Wrong mor X rror mor F a E ix dl zr cum On Negative File Decline Cust Bill To Not Equal To Ship To Decline Cust ix a A A A A A A A A Error ix a E Error E dl dad X 1 2 3 4 5 6 8 9 Bl B2 B3 B5 B7 B8 BB Invalid Pre approval Number Decline Cust Customer Service Phone Number required on Erro Fix Transaction Types 1 MO TO and 2 BE BF BH B BK
2. December 2006 Orbital Gateway Interface Specification Page 63 Field XML Name XML Parent Description Req Max Type Element M C O Char A N NewOrder Sets the Customer Reference Number that will be used to C 22 A utilize a Customer Profile on all future Orders CustomerRefNum Mandatory if Customer Profile Action Type Read Update or Delete Or Create and the Customer Profile Numbergeneration option S Use CustomerRefNum Element Keys If CustomerProfileFromO rderind A the Customer Reference Number will be defined by the Gateway and any value passed in this element will be ignored Given that this value can be the same asthe Order Number the valid charactersforthis field follow the same convention asthe Order ID element Those valid charactersare abcdefghijklmnop qrstuvwxyzA BC DEFG HIJ KLM NO PQRST UVWXYZ0123456789 9 amp and a space character However the space charactercannot be the leading character This value may not be changed through a Profile Update action CustomerProfileO rderOverridelnd NewOrder Defines if any Order Data can be pre populated from the C 2 A Customer Reference Number CustomerRefNum Mandatory if Customer Profile Action Type Create Optional if Customer Profile Action Type Update NO No mapping to orderdata OI Use lt CustomerRefNum gt for OrdernD and ECOrderNum or lt MailOrderNum gt OD Use lt CustomerReferNum gt for Comments
3. OA Use lt CustomerRefNum gt for OrdernD and Comments December 2006 Orbital Gateway Interface Specification Page 64 XML Parent Element uu l authentic ationEC IInd Field Type Max Char Description Req M C O Defines transaction type Conditionally required for Verified by Visa and MasterCard SecureCode transactions 5 Verified by Visa MasterCard SecureCode Authenticated Transaction 6 Verified by Visa Attempted Authentication Cardholder Authentication Verific ation Value use in Verified by Visa Transactions CAVV Thisnumber must be Base 64 Encoded Cryptographic value derived with an algorithm that appliesthe Issuer s private key to the combination of the Cardholderaccount number the Transaction Identifier XID and otherdata Transaction ID used in Verified by Visa Transactions XID This number must be Base 64 Encoded Unique tracking numberset by the Merchant and sent to the Issuer Authentication Service in the Authentication Request message Optional Defines the transaction type as a Prior Auth When this value is present the request is considered a force authorization No on line authorization will be generated to the Host systems Merchant Defined Order Number Field defined and supplied by the auth originator and echoed backin response The first 8 characters should be unique for each transaction Valid Characters abcdefghijkimnop qrstuvwxyzA BC
4. Key Customer Reference Numbers facts Must be unique either by Merchant ID or Chain ID see notes below Can be from 1 to 22 bytes in length Valid Characters are abcdefghijkImnopqrstuvwxyzABCDEFGHIJKLMNOPORSTUVWXYZ012345678 9 9 amp and a space character However Alpha characters always stored in uppercase Therefore this Setting the Customer Reference Number The merchant can either set or request that the Orbital Gateway set the Customer Reference Number December 2006 Orbital Gateway Interface Specification Page 37 The field customerProfileFromOrderInd controls this behavior as follows A Auto Generate the Customer Reference Number In other words the Orbital Gateway will assign the Customer Reference Number and return it in the response S The Orbital Gateway will use the value passed in the lt CustomerRefNum gt Element as the Customer Reference Number O This option only relates to when a Profile is added as a part of an authorization request In this circumstance the value passed in the lt OrderID gt element will be used as the Customer Reference Number This would be used in circumstances wherein the order ID also represents the Customer ID in your system such as a Policy Number for an insurance company D This option only relates to when a Profile is added as a part of an authorization request In this circumstance the value passed in the lt Comments gt element will be used as the
5. Intemet Web DEFAULT T Telephone December 2006 Orbital Gateway Interface Specification Page 59 Field XML Parent Description Req Max Type Element M C O Char A N NewOrder Defines the ECP payment delivery method C 1 A This field indicatesthe prefered mannerto deposit the transaction Conditionally required for Electronic Check processing B Best Possible Method US Only Chase Paymentech utilizes the method that best fits the situation If the RDFI is notan ACH participant a facsimile draft will be created Thisshould be the default value for this field A ACH US or Canadian Deposit the transaction by ACH only Ifthe RDFI is notan ACH participant the transaction is rejected AVSzip NewOrder Cardholder Billing Address Zip Code C 10 A AllAVS Requests must minimally include the 5 digit Zip Code Ifsending Zip Code 4 please separate with a Required forBill Me Latersale transactions AVSaddress1 NewOrder Cardholder Billing Address line 1 C 30 A Should not include any ofthe following characterstypes V I Required for Bill Me Latersale transactions AVSaddress2 NewOrder Cardholder Billing Address Line 2 O 30 A Should not include any of the following characters types V I AVScity NewOrder Cardholder Billing City C 20 A Should not include any of the following characterstypes V I Required for Bill Me Latersale transactions December 2006 Orbital Gateway Inter
6. lt SDProductDescription gt PRODUCT123 lt SDProductDescription gt lt SDMerchantCity gt lt SDMerchantPhone gt lt SDMerchantURL gt lt SDMerchantEmail gt PNS SUPPORT Rules and Guidelines Again the support for Soft Descriptors via the PNS Host is only for customers processing through Chase Paymentech Canada Unlike Salem the only value that gets passed on the Cardholder statement is the Merchant Name field And for these customers it is a maximum of 25 bytes of data All other Soft Descriptor fields can optionally be sent but will not be submitted to the settlement host and will not display on the cardholder statement Soft Descriptor Examples lt SoftDescriptor gt lt SDMerchantName gt XYZ PAYMENT1OF3 lt SDMerchantName gt lt SDProductDescription gt lt SDMerchantCity gt lt SDMerchantPhone gt lt SDMerchantURL gt lt SDMerchantEmail gt lt SoftDescriptor gt The Orbital Gateway includes functionality called Customer Profile Management which allows Cardholder data to be stored with the Orbital Gateway A merchant can process transactions by simply passing a token value that represents that cardholder Once a Profile is created transactions can be processed using either the on line interface or the Orbital Virtual Terminal VT simply by referencing the Customer Profile and filling in any additional information not stored in the profile This feature is only available to Merchants u
7. which identifies an approval 00 or the reason fora decline orermor Conditionally retumed when procStatus 0 CVV2RespC ode flexC acheResp Card verification value request response See appendix forvalues Conditional on card verification request being sent RespTime flexC acheResp Time the transaction was processed by gateway December 2006 Orbital Gateway Interface Specification Page 121 Quick Response Elements Note Forany request when the message cannot be delivered to the Host Authorization or Capture Systems A Quick Response message may be issued The relevant fields are Field XML Name XML Parent Description Req Max Type ESTEE ELEM EZH A N Response NA jReedXMLPaentg XML Parent Tag m AAA o p response MerchantiD QuickResp Gateway merchant ac count number assigned by Chase Paymentec h Solutions re D Echoesthe account number passed in the request LE TerminallD QuickResp Merchant Terminal ID assigned by Chase Paymentech M 3 Solutions 7 wf Echoes the Terminal ID passed in the request MIM OrdenD QuickResp Merchant Defined Order Number C 22 D EA QuickResp Card Number identifying the customer C 19 DT E C TxRefNum QuickResp Gateway transaction reference number C Dom emmuwmesemsoen eee 0 o wem wu wes O IN ProcStatus QuickResp Process Status M The first element that should be checked to determine the result of a request Itisthe only elementthat is retumed in all response scena
8. BL BM N B Recuning MC Only Issuer has flagged account assuspected Decline Cust fraud Discover Only Invalid MCC Sent Error Fix December 2006 Orbital Gateway Interface Specification Page 127 December 2006 Code Definition Status Action On Negative File Cust Insuffic ient Funds Cust EN Cust Fix mr ow ACH Non Participant Cust Orbital Gateway Interface Specification Page 128 Code Definition Status Action A E Fix al m es m e w fe em ad x ix A A A O o z z Z oj oj o y ol ojo alo gt Sl of oI 9 orl ct m S Oo c m d c 3 S 2 n gt a a zZ o o c 3 9 3 o D U uj g oj J gj m D j oO d EE EE ce s3 3 5 5 o oO Oo z zizimm A A 3 gt an z fe 2 O 5 D o i D ier 5 D z ix sL D VGE oW e m a ay B U N P 5 O lt gt y w EIE D 3 o D T D o g g D D o o 5 5 D D a z ix XN 2 lt ow U C c oO gJ oO A 5 D a ix T 5 5 lt lt S S occ 2 mg 3 3 a 2 c 3 o D oj J Oo O apa 3 5 0 O O d c np di X Block activation failed Card Range not set Error up forMOD 10 Block activation failed email or fulfillment Error flags were set to Y Declined Issuance doesn t meet minimum Cust amount N a x Ww a X I J2 i E ix z o un e 5 o o 3 g 0 o 5 p a a
9. These products offer a mechanism for securing the Internet channel by strongly authenticating the cardholder at the point of interaction by providing a unique transaction specific token that provides evidence that the cardholder originated the transaction December 2006 Orbital Gateway Interface Specification Page 14 How it works Verified by Visa Verified by Visa is based on the 3 D Secure Protocol which uses Secure Sockets Layer SSL encryption to collect and protect payment card information transmitted via the Internet It uses three domains for the authentication process e Issuer Domain Where the Issuer is responsible for determining whether authentication is available for the card account presented in a purchase e Acquirer Domain Where the Acquirer accepts Internet transaction data from the Merchant and passes it to Visa e Interoperability Visa Domain This is operated by Visa where transaction information is exchanged and stored using 3 D Secure as the common protocol Transaction Flow The cardholder shops at participating Internet Merchants with no changes to the shopping or checkout The cardholder selects the merchandise to be purchased and proceeds to the checkout At the checkout the cardholder may complete the purchase and payment information a variety of ways including self entered an electronic wallet Merchant one click or using other checkout capabilities After the purchase and payment information
10. for storage All Payer Authentication Response messages successful unable to authenticate failed and attempted authentications are transmitted and stored in the AHS The browser routes the Payer Authentication Response back to the MPI which validates the digital signature in the response verifying that it is from a valid participating Issuer If the digital signature is verified and the Issuer has sent an approved Payer Authentication Response the cardholder is deemed authenticated and the MPI returns the transaction to the storefront software The Merchant starts processing the order determining whether it can be fulfilled and calculating taxes and shipping for the total transaction amount The Merchant will send the CAVV ECI lt authenticationECInd gt of 5 authenticated transaction or 6 attempted authentication to the Orbital Gateway The CAVV must be sent in Base 64 encoding within the XML Document If the CAVV is not submitted in Base 64 encoding or if the CAVV is sent with a non eCommerce transaction a response code of 37 in the XML element lt RespCode gt will be returned Chase Paymentech will pass the CAVV and ECI along to Visa with the authorization request These fields are used during authorization processing to verify that authentication or attempted authentication was performed and to qualify for the eCommerce Customer Payment Services The Issuer receives the authorization request validates the CAVV and respon
11. orbital2 paymentech net authorize on port 443 Note Chase Paymentech exposes redundant hostname port network endpoints to ensure high availability for the Orbital Gateway Developers should code to December 2006 Orbital Gateway Interface Specification Page 45 Security a fail over URL When connectivity fails fail over to the secondary hostname port should be automatic Communication with the primary hostname port should be attempted periodically The fail over should be automatic and completely transparent to end user Caching IP Addresses of Orbital Gateway servers is strongly discouraged For load balancing and redundancy reasons the Orbital Gateway processing is divided amongst multiple data centers Therefore the DNS service should be used to determine the destination IP address for each transaction While the certification system is available for testing at all hours it is only monitored for availability during business hours 8 00am EST 5 30pm EST Monday Friday In addition the hardware in place is designed primary for certification testing not load testing If there is a need to ensure uptime outside of normal business hours please advise your certification analyst of the testing requirements Given the inherent risks associated with processing transactions over the Internet the Orbital Gateway requires both encrypted traffic to prevent interception of the Payload and authentication of the source r
12. whatever data is submitted on the first mark for capture will be used on all splits If each split should have different data then each MFC should include the relevant purchasing card data But that is not required If the data is not submitted on the auth then it must be included on the MFC for it to be submitted at Settlement o Where the amount submitted on the MFC is equal to the Auth the transactions is complete and that data will be used December 2006 Orbital Gateway Interface Specification Page 21 o Where the amount is less just as described above and a split transaction is generated whatever data is submitted on the first mark for capture will be used on all splits Purc hasing Card 3 Just as with Purchasing Card level 2 when processing level 3 data the additional data can be included in either the Auth and adjusted or added altogether via the Mark for capture transaction However because of the PNS based Purchasing Card Validation rules see edits above there is different behavior in terms of what can be done when adjusting the purchasing data via a Mark for Capture The following scenarios describe the optional behavior If the Purchasing data is submitted on the Authorization o No purchasing Card data is submitted on a Mark for Capture whether full or partial amount The gateway will submit at settlement the purchasing card data presented on the authorization Purchasing Card Data is submi
13. 100 000 00 should be sent as BM LC ustomerAnnuallnc ome gt 10000000 lt BM LC ustomerAnn uallncome gt Optional for Bill Me Later sale transactions BMLCustomerResidenceStatus NewOrder Customer Residence Status Valid Values O Own R Rent X Other Optional for Bill Me Later sale transactions BMLC ustomerC hec kingAc count NewOrder Customer Checking Account Indic ator Valid Values Y Yes customer hasa checking account N No customer doesnot have a checking account Optional for Bill Me Later sale transactions December 2006 Orbital Gateway Interface Specification Page 73 Field XML Parent Description Req Max Type Element M C O Char A N BMLCustomerSavingsAc count NewOrder Customer Savings Account Indicator Valid Values Y Yes customer hasa savings account N No customer does not have a savings account Optional for Bill Me Later sale transactions BMLProductDeliveryType NewOrder Delivery Type Indicator Valid Values CNC Cash and Cany DIG Digital Goods PHY Physical Delivery Required SVC Service TBD To Be Determined Optional for Bill Me Latersale transactions BillerReferenceNumber NewOrder Biller Reference Number PINLess Debit Only Reference Numberthe Biller merc ha nt uses on their system to identify this customer Conditionally required for PINLess Debit PCOrderNum NewOrder PO number or Order number from customer C 17 A Required for Purchasing Card Level 2 Data PCDestZip NewO
14. 17 1 2 2 sum sum 17 2 19 0 1 0 sum sum 19 0 19 1 2 2 sum sum 19 2 71 9 1 9 sum sum 21 9 30 9 2 18 sum sum 30 1 8 39 5 1 5 sum sum 39 5 44 1 2 2 sum sum 44 2 46 0 1 0 sum sum 46 0 46 4 2 8 sum sum 46 8 54 2 1 2 sum sum 54 2 56 5 2 10 sum sum 56 1 0 57 Remove the check digit 3 which is present in this example card sum 57 sum MOD 10 57 MOD 10 7 10 7 23 check digit of 5240159910151573 is 3 Continued on next page December 2006 Orbital Gateway Interface Specification Page 151 Example Coding for MOD 10 The following routine is a check digit routine written in the C programming language The operator for mod in C is long mod10 card card len 1 module 10 check digit function char card credit card number short card len card length register int count a counter register int weight weight to apply to digit being checked register int sum sum of weights register int digit digit being checked long mod weight 2 sum 0 p compute the sum for count 2 card len 1 count gt 0 count count 1 digit weight card count 0 add both the tens digit and the ones digit to the sum sum sum digit 10 digit 10 if weight 2 2 weight 1 else weight 2 subtract the ones digit of the sum from 10 and return the ones digit of that re
15. 2 Netherlands Antillean Guilder 532 2 New Guinea Kina 598 2 Nicaraguan Cordoba Oro 558 2 Nigerian Naira 566 2 North Korean Won 408 2 Pakistan Rupee 586 2 Pana manian Balboa 590 2 Paraguay Guarani 600 0 Peruvian Nuevo Sol 604 2 Philippines Peso 608 2 Polish Zoty 985 2 Qatari Rial 634 2 Romania Leu 642 2 Russia n Ruble 643 2 Rwanda Franc 646 0 Samoan Tala 882 2 Sao Tome amp Principe Dobra 678 2 Saudi Riyal 682 2 Seychelles Rupee 690 2 Sierra Leonean Leone 694 2 Slovak Koruna 703 2 December 2006 Orbital Gateway Interface Specification Page 142 Cunency Code Exponent Slovenian Tolar 705 2 Solomon Isla nds Dollar 090 2 So mali Shilling 706 2 South Korean Won 410 0 Sri Lanka Rupee 144 2 St Helena Pound 654 2 Sudanese Dinar 736 2 Swaziland Lila ngeni 748 2 Syrian Pound 760 2 Taiwan Dollar New 901 2 Tanzanian Shilling 834 2 Thai Baht 764 2 Tonga Pa anga 776 2 Trinidad amp Tobago Dollar 780 2 Turkish Lira New 949 2 Turkmenistan Manat 795 2 Uganda Shilling 800 0 Ukrainian Hryvnia 980 2 United Arab Emirates Dirham 784 2 Uruguayan Peso 858 2 Uzbekistan Sum 860 2 Vanuatu Vatu 548 0 Venezuelan Bolivar 862 2 Vietnamese Dong 704 2 Yemeni Rial 886 2 Yugoslavian Dinar New 891 2 Zambian Kwacha 894 2 Zmbabwe Kwacha Dollar 716 2 Purchasing Card 3 Tables ISO Country Codes ISO Code County UNITED KINGDOM DEU GERMANY ANC
16. 2006 Orbital Gateway Interface Specification Page 113 HexCache Request Hements Field XML Name XML Parent Description Req Max Type Element M C O Char A N eaea E IAN EE fexahe he Request uest XML tag that defines the transaction as a New Order request E A flexC ac Hs Transaction Routing Definition Assigned by Chase Paymentech 000001 Salem 000002 PNS flexCache Gateway merchant ac count number assigned by Chase Paymentec h This ac count number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID flexcache Merchant Terminal ID assigned by Chase Paymentech All Salem Terminal IDs at present must be 001 PNS Terminal ID s can be from 001 999 Most are 001 flexCache Card Number identifying the customer M 19 N Should be null for electronic check processing flexCache Merchant Defined Order Number M 22 A Field defined and supplied by the auth onginator and echoed back in response The first 8 characters should be unique for each transaction Valid Characters abcdefghijklmnop qrstuvwxyzA BC DEFG HIJ KLM NO PQRSTUVW XYZ0123456789 0 and a space character However the space charactercannot be the leading character December 2006 Orbital Gateway Interface Specification Page 114 XML Na me XML Parent Element MEM i CardSecVal flexcache u ShippingRef flexcache flexcache Description Transaction Amount
17. C O Char A N reed XYL Parane Tas endOfDay XML tag that defines the transaction as an Batch request endOfDay Transaction Routing Definition M N Assigned by Chase Paymentech 000001 Salem 000002 PNS Merc hantiD endOfDay Gateway merchant ac count number assigned by Chase M 15 N Paymentec h This account number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID TerminallD endOfDay Merchant Terminal ID assigned by Chase Paymentech M 3 N All Terminal IDs at present are OOT December 2006 Orbital Gateway Interface Specification Page 100 End of Day Response Elements Field XML Name XML Parent Description Req Max Type Element EE LE A N N A N A Response Loo Required XML ParentTag XML Parent Tag XMLtag A MEN PNE defines the transaction as a New Order possem em E EndOfDa yResp Gateway merchant account number assigned by Chase Paymentech Solutions Echoesthe account number passed in the request TerminallD EndOfDa yResp Merchant Terminal ID assigned by Chase Paymentech M 3 Solutions Echoesthe Terminal ID passed in the request Batc Batth amp qNum EndOfDayResp Sequence Number that References a Settlement Batch RESCUE E Proc po EndOfDa yResp Process Status The first element that should be checked to determine the result of a request Itisthe only elementthat is retumed in all response scenarios It identifies whethert
18. Customer Profile Action Type Update and the Customer Payment Type Credit card or Switch Solo Thisisthe equivalent to the lt AccountNum gt element used on transactional requests CCExpireDate Profile Customer Credit Card Expiration Date C 4 N Mandatory if Customer Profile Action Type Create and the Customer Payment Type Credit card or Switch Solo Optional if Customer Profile Action Type Update and the Customer Payment Type Credit card or Switch Solo Formats MMYY Salem C ustomerBIN 000001 allows a blank to be submitted when no known EXP date exists Please discussthis feature with your certification analyst before implementing There are three valid mechanisms for submitting a Blank expiration date using Orbitalto the Salem Host They are Nullfil this XML element lt Exp gt Send fourspaces lt Exp gt Exp Zero fill the XML Element lt Exp gt 0000 lt Exp gt This is the equivalent to the lt Exp gt element used on transactional requests December 2006 Orbital Gateway Interface Specification Page 107 Field XML Req Max Type XMLParentTag Description M C O Char A N ECPAccountDDA Profile ECP DDA Account Number C 17 A Mandatory if Customer Profile Action Type Create and the Customer Payment Type ECP Optional if Customer Profile Action Type Update and the Customer Payment Type ECP This isthe equivalent to the lt CheckDDA gt element used on transactional requests EC
19. Customer Reference Number Note Set field to EMPTY when using a customer profile lt CustomerProfileFromOrderlnd EMPTY gt This value is case sensitive Using the Customer Reference Number to set other data elements The Orbital Gateway has options in configuring the Profile setup in terms of how the Profile ID can be leveraged to populate other data sets using the lt CustomerProfileOrderOveridelnd gt value The options are NO No mapping to order data OI Pre populate the following fields with the Customer Reference Number o lt OrderID gt o lt ECOrderNum gt if it is an eCommerce Industry Type Transaction o lt MailOrderNum gt if it is an Mail Order or Recurring Industry Type Transaction OD Pre populate the Comments field Note this field is called Order Description in the Virtual Terminal with the Customer Reference Number The relevance of this feature is on the PNS platform BIN 000002 the Comments field is what populates the Customer Definable Data This data can then be made available on certain Resource Online Reports Any questions about your reports should be directed to your Relationship Manager OA Pre populate the following fields with the Customer Reference Number lt OrderID gt ECOrderNum if it is an eCommerce Industry Type Transaction lt MailOrderNum gt if it is an Mail Order or Recurring Industry Comments OwO O 0 December 2006 Orbital Gateway Interface Sp
20. DEFG HIJ KLM NO PQRSTUVW XYZ0123456789 0 and a space character However the space charactercannot be the leading character PINLess Debit transactions can only use upperand lower case alpha A Z a z and numeric 0 9 charactersand NO special characters December 2006 Orbital Gateway Interface Specification Page 65 XML Parent Element o XML Name ShippingRef p Description Transaction Amount Keys Implied Decimal including those currenciesthat are a zero exponent For example both 100 00 an exponent of 2 and 100 Yen an exponent of 0 should be sent as lt Amount gt 10000 lt Amount gt Free form comments Merchant can fill in this field and the info will be stored with the transaction details For PNS customers this field will populate the Customer Defined Data field which is displayed in Resource Online Shipping Trac king Reference Number Merchant can fill in this field and the info will be stored with the transaction details Defines the tax type Conditionally required for Purchasing Card Level Il Data 0 Not provided 1 Included 2 Non Ta xa ble Tax Amount forthe purchase Conditionally required for Purchasing Card Level Il Data Implied decimal including those currenciesthat are a zero exponent December 2006 Orbital Gateway Interface Specification Page 66 XML Name AMEXTranAdvAddn1 XML Parent Element mM AMEXTranAdvAddn3 AMEXTran
21. Description Action A December 2006 Orbital Gateway Interface Specification Page 133 December 2006 Code Description Action 2 3 40 54 205 208 301 303 328 329 330 331 333 335 348 350 351 355 400 410 411 516 518 519 521 523 801 803 804 PWS NETWORK ERROR Resend PWS DB ERROR Resend Unknown Database Issues Cannot Getto Authorizer Service Resend Ind ustry type is currently not supported for merchant and Fix An invalid amount submitted on a Partial Void Request PWS ERROR SPLIT AUTH NOT ALLOWED ALREADY MARKE Fix D PWS DID NOT ALLOW A CAPTURE REQUEST BECAUSE TH Fix E ORIGINAL AUTH WAS NOT SUCCESSFUL Fix Fix Fix Fix Fix Cannot Void a Transaction in which the Mark for Capture Failed The amount requested cannot be zero Fix This industry type does not allow a capture greaterthan the value ofthe auth There is nothing to capture This erroris retumed when a F Capture attempt is made on prior authorization but there is no amount left to capture PWS MANDATORY FIELDS ERROR Fix Fix ix FE NETWORK ERROR cannot connect to eHost Resend FE INTERRUPTED SESSION i o problem while connecting to Resend eHost The Merchant ID Acquiring BIN ID is invalid or missing Fix Message rejected This merchant is not active until This error is retumed Call when a Merchant Account has been setup but with an Customer Activation date in the future of the present da
22. Item Details included with this transaction Required for Purchasing Card 3 PC3DtiDesc PC 3Lineltem Purchase Card level 3 Line Item Detail Hement Description Text description of the item purchased Cannot be all zeros Required for Purchasing Card 3 PC3D ProdCd PC3Lineltem Purchase Card level 3 Line Item Detail Hement Product C 12 A Code Product code of the item purchased Purchase Card Level 3 Detail Header Required parent tag for Purchasing Card 3 Line Item Detail components Parent XML Tag for Individual Purc hase Card Level 3 Line Item Details Cannot be all zeros Required for Purchasing Card 3 PC3Lineltem Purchase Card level 3 Line Item Detail Hement Number of N Units Number of units of the item purchased Cannot be all zeros Required for Purchasing Card 3 Implied decimal of 4 December 2006 Orbital Gateway Interface Specification Page 90 XML Parent Element PC3Lineltem PC 3DUTaxAmt PC 3Lineltem i o Description Purchase Card level 3 Line Item Detail Hement Unit of Measurement The unit of measure orunit of measure code used forthis line item Required for Purchasing Card 3 See Table in Appendix A Purchase Card level 3 Line Item Detail Hement Tax Amount The tax amount forthis item Implied decimal Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Hement Item Debit Credit Indicator Valid Values D Item extended amount is
23. Keys Implied Decimal including those currenciesthatare a zero exponent For example both 100 00 an exponent of 2 and 100 Yen an exponent of 0 should be sent as lt Amount gt 10000 lt Amount gt See table for min max amount for each currency type Card Verification Data CVD PIN While the CVD value can be submitted on any transaction type the FlexCache Host will only validate the value on the following transaction types Authorize Redemption Balance Inquiry Free form comments Merchant can fill in this field and the info will be stored with the transaction details Shipping Trac king Reference Number Merchant can fill in this field and the info will be stored with the transaction details Defines the Industry type ofthe transaction MO Mail Ordertransaction RC Recurring Pa yment EC eCommerce transaction Req Max M C O Char December 2006 Orbital Gateway Interface Specification Page 115 XML Parent Description Req Max Element M C O Char Y Approve Redemption Completion Do not submit this Element if the desire isto not allow an Approvalon a Redemption Completion unless the full amount on the card is available Only supported for Salem Interfaces HexAction flexCache Defines the Transaction or Action Type The following are the valuesthat can be submitted Activate DeActivate ReActivate AddValue Auth Redemption RedemptionCompletion Refund Balancelnquiry Vo
24. PAccountlype Profile Defines the ECP deposit account type Mandatory if Customer Profile Action Type Create and the Customer Payment Type ECP Optional if Customer Profile Action Type Update and the Customer Payment Type ECP C Consumer Checking US or Canadian S Consumer Savings US Only X Commercial Checking US Only This is the equivalent to the BankAccountType element used on transactional requests EC PAccountRT Profile ECP Bank routing and transit number for the customer Mandatory if Customer Profile Action Type Create and the Customer Payment Type ECP Optional if Customer Profile Action Type Update and the Customer Payment Type ECP NOTE All US Bank Routing Numbers are 9 digits Al Canadian Bank Routing Numbers are 8 Digits This is the equivalent to the BC RENum element used on transactional requests December 2006 Orbital Gateway Interface Specification Page 108 Field Req Max Type XMLParentTag Description M C O Char A N Profile Defines the ECP payment delivery method C 1 A Mandatory if Customer Profile Action Type Create and the Customer Payment Type ECP Optional if Customer Profile Action Type Update and the Customer Payment Type ECP This field indicatesthe preferred mannerto deposit the transaction B Best Possible Method US Only Chase Paymentech utilizes the method that best fits the situation If the RDFI is notan ACH participant a facsimile draft will be created Thissh
25. PNS Host However December 2006 Orbital Gateway Interface Specification Page 32 o Itis only supported for Chase Paymentech Canada customers o The Merchant ID Terminal ID must be enabled for Soft Descriptors on the Orbital Gateway o The behavior is different from that of the Salem Interface Please refer to the PNS development section to understand how it works o Please contact you Chase Paymentech Representative SALEM SUPPORT Rules and Guidelines C redit Card The description in the merchant name field should be what is most recognizable to the cardholder It should consist of the company name and or trade name combined with some type of description of the product or service that was purchased Chase Paymentech will not generate or segregate reports by the Soft Descriptor If the Merchant wishes to see Salem reports segregated by product the Merchant must set up specific reporting divisions and deposit those transactions under that division number For those Merchants who need to roll up several merchant names under one corporation please contact your Chase Paymentech Representative for details on the use and regulation of the Soft Descriptors The Merchant Name can be one of 3 different Lengths o 3bytes o 7bytes o 12bytes An addition Product Description can be appended based on the length of the Merchant Name such that they are a combined length of 21 bytes In other words the options are o 18 by
26. Refunds must be voided before the end of day action whether auto settle or customer triggered Complex Type Name Void Request Reversal Void Response ReversalResp End of Day An End of Day request response instructs the gateway to submit all transactions previously marked for capture including all successful refunds for clearing Alternative End of Day methodologies include e Auto Settle At a Merchant ID level an account can be setup to settle automatically at any given 15 minute increment during the day and in any US based time zone e Virtual Terminal End of Days can be triggered using the Orbital Virtual as many times as desired Please see Virtual Terminal Users Manual for instructions Complex Type Name End of Day Request EndOfDay End of Day Response EndOfDayResp Quick response When a transaction has an error condition such as a time out condition or a poorly formed message request the gateway will generate a quick error message back to the requestor This error response takes the form of a Quick Response Complex Type Name Quick Response QuickResp December 2006 Orbital Gateway Interface Specification Page 12 Cardholder Authentic ation Card Not Present Address Venfic ation Address Verification also known as AVS is a cardholder authentication mechanism available to merchants In addition to providing merchants with an additional risk management tool it is required b
27. Response Elements Field XML Name XML Parent Description Req Max Type Element M C O Char A N SE flexC ac heResp XML tag that defines the transaction as a New Order request Merc hantiD flexC acheResp Gateway merchant ac count number assigned by Chase Paymentec h This ac count number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID OrdenD flexC acheResp Merchant Defined Order Number Field defined and supplied by the auth originator and echoed backin response AccountNum flexC acheResp Card Number identifying the customer 19 Should be null for electronic check processing flexC acheResp Merchant Teminal ID assigned by Chase Paymentec h M All Salem Terminal IDs at present must be 001 PNS Terminal ID s can be from 001 999 Most are 001 C C C StartAc countNum flexC acheResp Defines the first Card Number in a Block Activation 19 Sequence Batc hFailedAcctNum flexC acheResp Card Number in a Block Activation Sequence that caused a 19 N Block Activation Failure Conditionally retumed on a Block Activation failure flexRequestedAmount flexc acheResp Transaction amount submitted in the request C 12 N Implied Decimal Conditionally retumed December 2006 Orbital Gateway Interface Specification Page 118 Field XML Name XML Parent Description Req Max Type Element M C O Char flexRedeemedAmt flexC acheResp Actual amo
28. TID However there is no PNS Chain value So the Orbital Gateway assigns the next available chain value when setting up accounts for the first time If an organization has multiple Merchant IDs there is no guarantee that all of those Orbital Gateway Merchant ID s will be linked under a single Chain ID However Merchant IDs can be moved under one chain to take advantage of this feature Profile Transaction Types There is a number of transaction types associated with Profiles Some of these are extensions of existing transaction types and some are new to profiles This section will detail from an XML perspective how to support all those Profile transaction types and some of the specific rules associated with each of them Again all of the functionality identified within this document is possible through the Virtual Terminal as well Managing Profiles There are a set of transactions specifically set up for managing the Profile in other words adding updating deleting and retrieving the information Adding Profiles First and foremost a profile needs to be added to the Orbital Gateway There are two different transaction actions that can be performed to add a profile Adding Profiles as a Stand Alone Transaction The simplest mechanism is to add a Profile is to simply make a Profile Add Request Type This document includes both the definition of the XML elements necessary to complete this transaction and an example template of a
29. X D x o D 3 ke T O 5 2 3 D D g D 9 5 D a x December 2006 Orbital Gateway Interface Specification Page 129 Code Definition Status Action K7 Future RD Six N A Transaction Code Conflict Fix 12 Process Unavailable Error Resend L4 Invalid Effective Eror Fix AVSRespCode Tag Values Code AVS Message No address supplied Bill to address did not pass Auth Hos edit checks AVS not performed Issuer does not participate in AVS Edit error AVS data isinvalid December 2006 Orbital Gateway Interface Specification Page 130 System unavailable ortime out Address information unavailable e 000007 E EN s EAN p EI A E A AAA No match at all Zp Match Locale match Issuer does not participate in Global AVS DENM Intemational street address and postal match J JA y Intemational postal code match Street address not verified Cardholder name matches Cardholder name billing address and postal code matches Cardholder name and billing code matches Cardholder name and billing address match M5 Cardholdername incorrect billing addressand postal code match M6 Cardholder name incorrect billing address matches M O Cardholder name incorect billing address matches M6 M7 incomect ZP matches address not verified Addressand ZP code match Intemational only mm Zip Match Zip 4 Match Address Match Not Performed Zp Match Locale no match Dec
30. a limited number of password attempts typically 3 to 5 as defined by the Issuer ACS If unable to correctly enter the password the cardholder may access the password hint that was established during the registration If the password is entered correctly the transaction continues If the cardholder is not registered the ACS briefly displays a processing window and the transaction continues as an attempted authentication If the password is incorrectly entered more times that the Issuer limit the failed Payer Authentication Response is returned to the Merchant December 2006 Orbital Gateway Interface Specification Page 15 The Issuer ACS retrieves the authentication information and compares it against the data that was registered during the initial registration process If the data matches a success page is presented to the cardholder and the Issuer ACS sends a message through the browser to the merchant thus providing evidence of cardholder authentication Using the Issuer s encryption keys and transaction data the Issuer server calculates the Cardholder Authentication Verification Value CAVV which will be included with the Electronic Commerce Indicator ECI as provided at the time of authentication by the MPI in the response to the Merchant The Issuer ACS creates digitally signs and sends a Payer Authentication Response to the cardholders browser and sends transaction information to the Visa Authentication History Server AHS
31. amp Orbital Orbital Gateway Interface Specification V 4 2 12 01 06 CHASE amp Paymentech Change Log Date Action Description of Change 09 01 06 Rewrite Orbital Gateway Version 4 0 isa brand new schema that requiresthe specification to be rewritten 11 01 06 Updated Added Bil Me Later in Schema version 4 1 12 01 06 Updated Added PINLess Debit December 2006 Orbital Gateway Interface Specification Page 2 Introduction Table of Contents Chase Paymentech Orbital Gateway Transaction Processing Model 8 Transaction Pesados 9 New Order ssanie M 9 Plex Cache Trans acond dada 10 Profile Transaction Types dni 10 Mark for Capture MFC nata teg ate dates 10 Reversal Void a Previous Transaction ssss 11 End of Day m M 12 Quick TES PONS ica 12 Cardholder Authentication Card Not Present sss 13 Address Vertical anita 13 Card Verification Numbers iu ener ennt ten ee csi 13 Verified by Visa MasterCard SecureCode Programs 14 Purchase COEPoeu eevsattesta tibia 20 Introduction DE 20 Edit COCKS i A 20 BIN RANGES md 21 Erre Ma 21 Buropean Direct Debian a teens aaa 23 troduction nat 23 PICK CAG cr HQ 24 Transaction LY pes scc te td 24 RESPONSES eei estie Kao eder ie 28 Setenta 28 REPO A AA Atl 28 Bil Me Later RA 28 Ntro dc E 28 How 3t WODKS epe
32. and collecting funds for outstanding invoices Merchants have the ability to collect their funds in conjunction with the settlement of their credit card transactions and still provide their customer with the necessary line item detail thus providing a cleaner process for both the merchant and their customer Edit Checks The Orbital Gateway performs edit checks on incoming data to ensure necessary information is present In the event necessary information is missing from a transaction the transaction will result in an error see list of error codes in the ProcStatus listing in Appendix A Data fields that are edited by Chase Paymentech have been marked as Conditionally Required in the Transaction Management section of this document Additionally there some special edit checks specific to each host described below PNS There are two key mathematical data validations specific to PNS processing for Purchasing Card 3 Processing The amount field lt PC3Dtllinetot gt of every line item must equal the Unit Cost lt PC3DtlUOM gt multiplied by the quantity lt PC3DtlQty gt less any discounts lt PC3DtlDisc gt If it does not then this transaction will receive an error Additionally the sum of all the Line Item totals lt PC3Dtllinetot gt cannot exceed the transaction amount lt Amount gt submitted for an order December 2006 Orbital Gateway Interface Specification Page 20 Salem There is no mathematical val
33. apture Purchase Card Level 3 Duty Amount for Shipment 12 N Total charges forany import and or export duties included in this transaction Implied decimal PC3DestC ountryCd markForC apture Purchase Card Level 3 Destination Country Code 3 A The ISO assigned code of the country to which the goods are shipped Conditionally required forall Purchasing Card 3transactions If no value is submitted it will be default to the United States USA Required for Purchasing Card 3 See Table in Appendix A PC3ShipFromZip markForC a pture Purchase Card Level 3 Ship from Zip 10 A The zip postal code ofthe location from which the goods are shipped Required for best Interchange rate and cannot be allzeros or nines PC3Disc Amt markForC apture Purchase Card Level 3 Discount Amount from Order 12 N The total amount of discount applied to the transaction by the merchant Used by the merchant when a price break is given on an entire transaction ratherthan on unit prices Typically this is Shown asa credit on a detailed invoice Implied decimal Optional for Visa only Should not be sent for MasterCard December 2006 Orbital Gateway Interface Specification Page 88 Description Max Field XML Parent Char Type Element A N markForC apture Purchase Card Level 3 Total Amount of VATorother tax N The total amount of VATorothertax expressed in percentage terms forthisline item 2 decimal implied Example 0001 196 Optional for Visa only Should not
34. be sent for MasterCard PC3VATtaxRate markForC a pture Purchase Card Level 3 Rate of VATorothertax N The total amount of VATorothertax included in this transaction Implied decimal Optional for Visa only Should not be sent for MasterCard PC3AltTaxID markForC apture Purchase Card Level 3 Altemate Tax ID N TaxID numberforthe altemate tax associated with this transaction OptionalforMasterCard only However required if an amount is sent in PC3AltTaxAmt Should not be sent for Visa PC3AltTaxAmt markForC apture Purchase Card Level 3 Altemate Tax Amount N Total Amount of altemate tax associated with this transaction Implied decimal OptionalforMasterCard only However required if an amount is sent in PC3AltTaxID Should not be sent for Visa PC3LineltemCount markForC apture Purchase Card Level 3 Number of Line Items N The number of Purchasing Card 3 Line Item Detail items included with this transaction The maximum number of line itemsis 98 Atleast 1 line item must be included to submit Purchasing Card 3 data Required for Purchasing Card 3 December 2006 Orbital Gateway Interface Specification Page 89 Description Max Field Description XML Na me XML Parent Element PC 3Lineltem PC 3LineltemAma y EE This XML Tag isthe parent foreach Line item detail included in thistransaction It should be repeated foreach item PC3D index PC3Lineltem Purchase Card Level 3 Line Item Index The sequential number 1 98 of the Line
35. ble to Perform Profile Transaction The Associated Call Transaction Failed 9577 Invalid OrderOvenide Indicator 9578 Merchant Bin combination is not allowed to perform Call profile transactions combination A database erorhas occurred Num and MID Num and MID Cannot Create Profile A Customer Profile Name is Fix Required 9583 Missing Switch Solo Account Information Either start date or issue number is required CunencyCode and CurrencyExponent Tag Values Cunency Code Exponent Albanian Lek 008 2 Algerian Dinar 012 2 Angolan New Kwanza 982 2 Argentine Peso 032 2 Armenian Dram 051 2 Aruban Guilder 533 2 Azerbaijanian Manat 031 2 Bahamian Dollar 044 2 Bangladeshi Taka 050 2 Barbados Dollar 052 2 Bela russia n Ruble 974 0 Belize Dollar 084 2 Bermudian Dollar 060 2 Bolivian Bolivia no 068 2 Bosnia Convertible Mark 977 2 Botswana Pula 072 2 Brazilian Real 986 2 Brunei Dollar 096 2 Bulgarian Lev 975 2 December 2006 Orbital Gateway Interface Specification Page 140 Cunency Code Exponent Burundi Franc 108 0 Cambodian Riel 116 2 Cape Veni Escudo 132 2 Cayman Islands Dollar 136 2 Cfa Franc Bceao 952 0 Cfa Franc Beac 950 0 Cfp Franc 953 0 Chilean Peso 152 2 Chinese Yuan Renminbi 156 2 Colombian Peso 170 2 Comoro Franc 174 0 Costa Rican Col
36. is entered the cardholder selects the buy button This activates the Merchant Server Plug In MPI software application which checks its local cache to determine if the Visa Issuer BIN participates in Verified by Visa If the BIN is participating the MPI will generate an inquiry to the Visa Directory Server to determine if the cardholder s account is enrolled in Verified by Visa The Visa Directory Server sends a Verify Enrollment Request message to the Issuer Access Control Server ACS to determine if authentication is available for the cardholder s account number The Visa Directory Server sends the Issuer ACS response to the MPI If authentication is not available the Merchant server receives an authentication not available message and returns the transaction to the Merchant s commerce server to proceed with a standard Authorization request If authentication is available the message response provides the URL for the Issuer ACS where the cardholder can be authenticated The MPI sends a message and script directing the cardholder s browser to establish a pop up session with the Issuer ACS The browser directs the transaction to the URL specified for the Issuer ACS creating an SSL session The Issuer ACS displays a inline web page to the cardholder The page includes Issuer specific and Visa branding transaction details including Merchant name and sale amount and prompts the cardholder to enter their password The cardholder is allowed
37. passing the FlexPartialRedemptionInd element with a value of Y Auto Authorization of the Remainder As stated above when a Redemption Completion is submitted for an amount that is less than original amount the entire original balance on hold is removed and the new amount redeemed from the card If the transaction was a split shipment however the merchant might want the card to maintain a hold on the balance for the remaining un redeemed amount To re establish this hold on the funds a new authorization needs to be submitted This new authorization can either be a whole new request submitted by the merchant o Or when performing the Redemption Completion the Element lt FlexAutoAuthInd gt can be passed in the Mark For Capture request with a value of Y When this happens if the initial Redemption Completion is successful the Orbital Gateway will automatically generate a new Authorization Request for the amount that represents the un redeemed amount from the initial Authorization o Return a single response identifying the result of the Redemption Completion and if it was successful the new authorization request If there is a new authorization the following aspects of the response are important to understand There will only be one set of Current and Previous Card Balances returned and those values will be reflective of the result of both actions If the new authorization request is successful the new authorizat
38. section will provide some background information on supporting these programs The value for these cards is 3 digits and can be found on the signature panel on the reverse side of the credit card and is represented by the three digits following the account number This value may not be stored at all Not even for future transactions as it is against regulations to do so December 2006 Orbital Gateway Interface Specification Page 13 The use of this value provides an important security check due to the fact that only the individual in possession of the actual credit card will be able to provide the value to the merchant Statistics validate those individuals who may know the account number but are not in possession of the actual credit card perpetrating much of the fraud occurring in the non face to face environment When a merchant collects this value and passes it in the authorization request Chase Paymentech passes this data through the authorization system to the card issuer In the authorization response the card issuer validates the accuracy of CVV2 CVC2 Discover CID value for the specific card Used in conjunction with the valid expiration date this service provides a valuable tool for assessing the true cardholder has placed the order with you for your services or product American Express CID Merchant Processing Requirements American Express provides a similar program to Visa MasterCard and Discover except with a few diff
39. the profile For example if the card type of a Profile is a credit card then the base credit card message structure should be used to use the profile The credit card data again would simply be null filled Overriding Profile Data Almost any data set in the Profile can be overridden during a transaction that is using the Profile For instance if a Profile included a fixed amount but a particular transaction was for a different amount it could be changed for that transaction by including a specific amount in the use profile request The one exception to the override rule is the payment type such as Credit Card versus ECP cannot be overridden If the Payment is different then the Profile should either be Updated if that change is permanent or not used if it is temporary By the same token if the payment type is the same but the data is different it can be overridden on a single transaction if desired Finally overriding Profile data does not update the profile If the change is permanent an Update Profile request should be sent in Expiration Date One scenario to take into consideration when overriding data has to do with the usage of expiration dates As defined in the spec for a Salem customer a null Expiration date is one mechanism to submit transactions for authorization when the expiration date is unknown By the same token Expiration Date is a required tag for credit card transactions and must be present when Usin
40. to determine the result of a request Itisthe only element that is retumed in all response scenarios It identifies whethertransactions have successfully passed all of the Gateway edit checks 0 Success All other values constitute an error condition See appendix for definition of those error values ApprovalStatus NewOrderResp Approval Status C n o N N Conditional on Process Status retuming a 0 or successful response If so approval status identifies the result of the authorization request to the host system 0 Decline 1 Approved 2 Message System Error December 2006 Orbital Gateway Interface Specification Page 82 Field XML Name XMLParent Description Req Max Type Element M C O Char A N RespCode NewOrderResp Response Code C 2 A Normalized authorization response code issued by the host system Salem PNS which identifies an approval 00 or the reason fora decline or emor See appendix for values AVSRespCode NewOrderResp Address verification request response M 2 A See appendix for values Conditional on AVS request being sent CVV2RespCode NewOrderResp Card verification value request response See appendix forvalues Conditional on card verification request being sent AuthCode NewOrderResp Issuer approval Code Unique transactional level code issued by the bank or service establishment for approvals PINLess Debit transactions could retum blanksorN A RecuningAdviceCd NewOrde
41. transactions against both the Test and Production Orbital Gateway the client servers Source IP or Source IP s must be registered in the Orbital Gateway Any activity presented on an IP address that is not registered in the Orbital Gateway will result in an HTTP 412 error with the accompanying XML payload containing a ProcStatus 20412 error see documentation for definition of these error fields e n addition these IP addresses must be affiliated the Merchant ID s for which the Client should be submitting transactions Specifically o This does allow Third Party Hosting service organizations presenting on behalf of other merchants to submit transactions However each time a new customer is added the merchant or Third Party hosting organization needs to ensure that the new Merchant ID s or Chain ID s are affiliated with the hosting companies IP s o If the merchant expects to have more than one merchant account with the Orbital Gateway it should have its IP addresses affiliated at the Chain level hierarchy within the Orbital Gateway Each time a new merchant ID is added as long as it is placed within the same Chain it will simply work Otherwise the additional MID s will need to be affiliated with the merchant IP s For example we generally affiliate all Salem accounts BIN 000001 with their Company Number formerly called MA number so all MIDs or Divisions under that Company will automatically be affiliated e P Failure and MID F
42. will identify specifically what transaction type is being reversed such as Reversal Redemption in the lt FlexAction gt tag See section 0 for more information on responses December 2006 Orbital Gateway Interface Specification Page 27 Balance Inquiry This transaction will perform a Balance Inquiry Responses The basic authorization response for all FlexCache transactions is the same In other words all responses will be returned in the same basic XML Document form with the same base minimum data elements The transactions types that will include more information are Block Activations if they fail Redemption Completions with the Partial Redemption Flag Redemption Completions with Auto Authorization behavior Settlement Since transactions affect the balance of a card real time FlexCache transactions are not affected by the End of Day process options Instead transactions will automatically fall into one of two buckets when viewed through the virtual terminal Open FlexCache items This will include all un settled activity o Authorizations that have not been redeemed Redemption Completion o Declined transactions o Errors In the Review section of the Virtual Terminal all Redeemed items will be viewable These items will be grouped on a daily basis on the same timing as the FlexCache System reports activity which is 5am 5am Reporting All true FlexCache reporting is available from the FlexCac
43. 3 Merchant sends MFC for 30 3c New Unmarked order systemically created for remainder of split 50 3a System performs Auth request for 30 3b Unmarked 80 transaction now MFC for 50 4 Merch sends MFC for 10 4a Syst Performs Auth for 10 4b Unmkd 50 now MFC for 10 4c New Unmarked order systemically created for remainder of split 40 5 Merchant sends MFC for 40 5a System performs new Auth request for 40 5b Unmarked 40 now MFC for 40 TRANSACTION KEY Authorization Request Marked Transaction C viario apta MFC Request IA Unmarked Transaction Complex Type Name Mark for Capture Request MarkForCapture Mark for Capture Response MarkForCaptureResp Reversal Void a Previous Transaction This transaction is for voiding a previous transaction except FlexCache Transactions either in the full amount or partial If a Reversal void request is sent for a partial amount the transaction will be split into two components A voided transaction in the amount of the partial void request and the remainder of the previous transaction in the same state the full amount was previously Authorized or Marked for Capture Notes December 2006 Orbital Gateway Interface Specification Page 11 e A Reversal Void transaction does not reversal the original Authorization for any card type other than FlexCache e Transactions can not be voided once they have settled So Captured Authorizations and
44. 3 data relevant to that component and for PNS Tampa customers it must additionally match the amount based on the edits of the MFC December 2006 Orbital Gateway Interface Specification Page 22 Virtual Terminal All of the functionality supported through this interface for Purchase Card 2 and 3 is additionally available through the Orbital Gateway Virtual Terminal European Direct Debit Introduction Overview European Direct Debit EU DD is a popular method of payment for merchants marketing in Europe While any merchant may want to accept direct debit payments it is most important and cost effective for those merchants collecting recurring payments Unlike in the US many EU customers prefer to pay for recurring services by direct debit to their bank accounts This is especially true in Germany where almost 40 of all electronic payments are made by direct debit How it works In Europe each country operates its own direct debit network Merchants wishing to accept direct debit throughout Europe would face the requirement to establish banking relationships and technical integration for each country in which they wish to market Chase Paymentech Solutions has created a single technical interface for direct debit processing for multiple countries Processing Requirements Merchants must contract with Chase Paymentech Solutions for acceptance of European Direct Debit The Merchant Descriptor is defined on the vendor s syst
45. AdvAddn4 Field Description Max Type Char Amex Purchasing Card Data Transaction Advice Addendum 1 The TAA Record is used to further identify the purchase that is associated with the charge to the cardholder It isalso used in Purchasing Procurement card transactions to provide specific details about the transaction to the cardholderfortracking purposes TAA sshould be as concise aspossible A TAA of Merchandise for example would not be acceptable Salem Only Conditionally required for Amex Purchasing Card Data Amex Purchasing Card Data Transaction Advice Addendum 2 Salem Only Conditionally required for Amex Purchasing Card Data Amex Purchasing Card Data Transaction Advice Addendum 3 Salem Only Conditionally required for Amex Purc hasing Card Data Amex Purchasing Card Data Transaction Advice Addendum 74 Salem Only Conditionally required for Amex Purchasing Card Data Accountholder Authentic ation Value for MasterCard Secure Code Conditionally required for MasterCard SecureCode transactions This number must be Base 64 Encoded Unique transaction token generated by the issuerand presented to the merchant each time a cardholder conductsan electronic transaction using MasterCard SecureCode AAV incorporates elements specific to the transaction and effectively bindsthe cardholderto a transaction at a merchant fora given salesamount December 2006 Orbital Gateway Interface Specific
46. BIN 000002 Add Value This transaction type adds value to an active card If an Add Value is performed on an inactive card it will both activate the card and perform the add value action as well Merchants processing to the PNS Host can process Prior Add Value Transactions by additionally passing the correct prior approval code If the valid Prior Approval code is not passed it will be treated as a new Add Value request Salem Merchants attempting to process a Prior Add Value will receive an error response Purc hase and Refund Transactions The following transaction types are for purchases and refunds There are two different transaction combinations available for purchases 1 Authorization followed by a Redemption Completion This transaction combination is only valid for Salem based customers 2 Redemption These two combinations allow for different purchase processing behavior on FlexCache cards This section will define how each transaction type functions Authorization Almost all FlexCache transaction types immediately affect the card balance meaning add or reduce the funds based on the result In some circumstances there might be a desire to perform a sale wherein an authorization is performed and the funds not actually moved One reason for this for example might be a deferred shipment of goods The Authorization transaction does exactly that It will reduce the Available to Buy amount without actually reducing
47. Chase Paymentech 000001 Salem 000002 PNS MerchantiD markForC apture Gateway merc hantac count number assigned by Chase Paymentec h This account number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID TerminallD markForC a pture Merchant Terminal ID assigned by Chase Paymentech M 3 All Terminal IDs at present are 001 M 40 TxRefNum markForC apture Gateway transaction reference number A A unique value for each transaction which is required to adjust any transaction in the gateway such as Mark for Capture orvoid markForC apture PO number or Order number from customer A Required for Purchasing Card Level Il Data PC DestZip markForC apture Shipping Destination Zip code for the purchase A Required for Purchasing Card Level Il Data ForZp Code 4 please separate with PCDestName markForC apture Amex Purchasing Card Data 30 A O Bd ea eranen O December 2006 Orbital Gateway Interface Specification Page 86 XMLName XML Parent Element markForC apture Salem Only Required for Amex Purchasing Card Data PCDestAddress2 markForC apture Amex Purchasing Card Data Cardholder Ship To Address line 2 Salem Only Required for Amex Purchasing Card Data PCDestCity markForC apture Amex Purchasing Card Data Cardholder Ship TO City 20 Salem Only Required for Amex Purchasing Card Data PCDestState markForC apture Amex Purchasing Card Dat
48. E RE December 2006 Orbital Gateway Interface Specification Page 143 ISO Code County CZECH REPUBLIC DENMARK FINLAND HUN HUNGARY ISL ICELAND reus ISR ISRA EL PEPA is m mw SWEDEN SWITZERLAND UNITED STATES UNITED ARAB EMIRATES AUSTRALIA HONGKONG JAPAN MALAYSIA NEW ZEALAND ZAD SOUTH AFRICA Unit of Measure UOM Code Unit Name Alcoholic strength by mass Alcoholic strength by volume December 2006 Orbital Gateway Interface Specification Page 144 December 2006 UOM Code Unit Name Brake horse power 245 7 watts BU British themal unit 1 055 kilojoules BUA Curie s O Cure Degree Kelvin see Kelvin 00000000 DANN Dozen DZ Dozenpacks o Orbital Gateway Interface Specification Page 145 December 2006 UOM Code Unit Name QDs OZ Fluid ounce 28 413cm3 Gigawatt hour 1 million KW h Great gross 12 gross HAR Hectare HBA Hectobar 34 2 O DH Hectokilogam_______________ HZ Hertz C CLF Hundred leaves Hundredweight US 45 3592 kg Inch 25 4 mm JOU Joule Joue o O KEL KBA JKlobar KSH Kilogram of caustic soda Cid Kilogram of pota sium oxide KsD_ Kilogram of substance 90 dry Cd N HAR HBA DTH HIZ Hundred boxes LF INH OU KBA KSH Orbital Gateway Interface Specification Page 146 December 2006 UOM Code Unit N
49. Gateway validates the Trace Number and Merchant ID to determine if it has processed a transaction using that value pair within a 48 hour window If the transaction is a decline or error on the initial response the next request will be treated as a new request If it has not processed the pair the Gateway will treat that transaction as a new request and process it accordingly If it has processed the pair and the Request has either already been processed the initial response is an approval or is in process the Orbital Gateway will December 2006 Orbital Gateway Interface Specification Page 51 immediately echo back the exact response XML Document from the initial request Ifthe initial Request is still in process the Orbital Gateway will block and wait until that original response is completed As soon as that is done it will then echo back the same response as the original request The following sections outline the detail business rules and implementation considerations associated with Retry Logic Retry Timing The Orbital Gateway only retains an original Retry Trace number Merchant ID pair for 48 hours after submission Any transactions that reuse these values more than 48 hours after the original transaction was submitted will be treated as a new request Therefore if there is an unknown result for a transaction then that transaction must be reattempted within 48 hours or the result will need to be determined thr
50. L Parent Description Req Max Type Element M C O Char A N Recuningind NewOrder Recuning indicator This tag is conditionally required for Merchants that are Located inCanada Processing on BIN 000002 Industry Type Recuning The valid valuesare RF First Recuning Transaction RS Subsequent Recurring Transactions EUDDCountryCode NewOrder European Direct Debit Country Code Customers Country Code The following is the list of valid country codes AT Austria BE Belgium DE Germany FR France GB United Kingdom NL Netherlands EUDDBankSortC ode NewOrder European Direct Debit Bank Sort Code Customer s Bank Sort code Mandatory forthe following Country Codes AT Austria DE Germany FR France GB United Kingdom ae NewOrder eee l Direct Debit RIB ome OE ee Bank Account checksum used in France only BMLCustomenP NewOrder Customer s IP Address D TT E PPP BMLCustomerEmail NewOrder Customer Email Address AA NEN December 2006 Orbital Gateway Interface Specification Page 71 Field XML Name XML Parent Description Req Max Type Element M C O Char A N BMLShippingCost NewOrder Total Shipping Costof Consumers Order C N A AA esencia BMLINC Version NewOrder Terms and Conditions Number The Termsand Conditions Numberto which the consumer agreed Mandatory for Bill Me Later sale transactions BMLC ustomerRegistrationDate NewOrder Customer Registration Date The date a customer registered with the merchant M
51. ML Parent Element flexC acheResp flexC acheResp flexC acheResp flexC acheResp flexC acheResp Description Req M C O Gateway transaction reference number M A unique value foreach transaction which is required to adjust any transaction in the gateway Gateway transaction index Used to identify the unique components of transactions adjusted more than one time Required on forvoid transactions Process Status The first data set that should be checked to determine the result of a request Itisthe only element that is retumed in all response scenarios It identifies whethertransactions have successfully passed allof the Gateway edit checks 0 Success All other values constitute an emorcondition and will be retumed in a SOAPFault See appendix for definition of those error values Approval Status Conditional on Process Status retuming a 0 orsuccessful response Only Retumed if performing a MFC ona FlexCache Card Type If so approval status identifies the result of the authorization request to the host system 0 Decline 1 Approved 2 Message System Error Issuer approval Code Unique transactional level code issuer usesto show each request wasapproved December 2006 Orbital Gateway Interface Specification Page 120 XML Name XML Parent Description Element RespCode flexC acheResp Response Code Normalized authorization response code issued by the host system Salem PNS
52. NTTO THE lt AVSPHO NENUM gt ELEMENT USED ON TRANSACTIONAL REQUESTS Defines if any Order Data can be pre populated from the Customer Reference Number C ustomerRefNum Mandatory if Customer Profile Action Type Create Optional if Customer Profile Action Type Update NO No mapping to orderdata OI Use lt CustomerRefNum gt for OrdernD and ECOrderNum or MailO rderNum OD Use lt CustomerReferNum gt for Comments OA Use lt CustomerRefNum gt for OrdernD and ECOrderNum or lt MailOrderNum gt and Comments Defines the Customer Profile action desired M C Create a Customer Profile U Update a Customer Profile R Retrieve a Customer Profile s Attributes D Delete a Customer Profile This element is only used for Customer Profile Management actions December 2006 Orbital Gateway Interface Specification Page 105 CustomerProfileFromOrderind OrderDefaultDesc ription OrderDefaultAmount XML Parent Tag Profile Profile Profile Field Req Max Type Description M C O Char A N Customer Profile Number generation Options M 5 A A Auto Generate the CustomerRefNum S Use CustomerRefNum Element When performing an action otherthan a Customer Profile Action Type Create insert empty asit will be ignored But this Attribute is mandatory and cannot be null filled Order Description Optional if Customer Profile Action Type Create or Update If the CustomerProfileOrderO
53. P Version ft Content Type This MIME Header field is used by the Client to identify which DTD version is being used for the XML Payload e The format data for this field is application XSD Version e The latest Version and recommended value is PTI41 e Assuch the recommended value for this field is application PTI41 NOTE Versions PTI40 and above are not backward compatible with XML documents created in DTD version created in PTI34 and earlier All prior DTD versions are still supported but require the Mime Header to identify the version as PTI34 or lower Any new functionality exposed after PTI34 requires coding to the new XSD specification Merchant id This MIME Header field is used in combination with the Trace number as the key transaction identifiers as it relates to Retry Logic This field must be populated with the same Merchant ID as submitted in the XML payload i e lt MerchantID gt 123456789012 lt MerchantID gt If the Merchant ID is not the same the Orbital Gateway will return an error in the form of a Quick Response with a ProcStatus of 9713 Invalid mime header Merchant ID in mime does not match XML message see section 4 for complete description of Retry Logic specific error codes Trace number This MIME Header field is used in combination with the Merchant id as the key transaction identifiers as it relates to Retry Logic The Trace number Field rules are Data Type Numeric Minimu
54. Page 69 XML Name SDMerc hantEmail XML Parent Element NewOrder NewOrder NewOrder Field Description Req Max Type M C O Char A N Soft Descriptor Merc hant Phone C 12 A Tag conditionally required for Soft Descriptors Only one ofthe location Soft Descriptorrecords should be sent meaning Phone URL or Email This field will notshow on Cardholder statements for PNS Merchants Valid Formats NNN NNN NNNN NNN AAAAAAA NOTE ForMasterCard MOTO Transaction Type 1 and Recurring Transaction Type 2 if the City Phone field at the division level is not a Customer Service Phone Number then a Customer Service Phone Number must be populated in the Merchant city Customer Phone Numberfield orthe transaction will reject with Response Reason Code BP Missing CustomerService Phone Soft Descriptor Merchant URL Tag conditionally required for Soft Descriptors can be null filled Only one of the location Soft Descriptor records should include data meaning Phone URL or Email This field will notshow on Cardholder statements for PNS Merchants Soft Descriptor Merchant Email Tag conditionally required for Soft Descriptors can be null filled Only one of the location Soft Descriptor records should include data meaning Phone URL or Email This field will notshow on Cardholder statements for PNS Merchants December 2006 Orbital Gateway Interface Specification Page 70 Field XML Name XM
55. Parenttag XML Parent Tag E IE XMLtag A ee defines the transaction as a New Order response MerchantiD MarkForCaptureResp Gateway merc hant ac count number assigned by Chase Paymentec h Solutions Echoesthe account number passed in the request TerminallD MarkForCaptureResp Merchant Terminal ID assigned by Chase Paymentech M 3 Solutions Echoesthe Terminal ID passed in the request OrdenD MarkForC aptureResp Merchant Defined Order Number M 22 Echoesthe Order Number passed in the request TxRefNum MarkForCaptureResp Gateway transaction reference number M Echoes the Transaction Reference Number passed in the request MarkForCaptureResp Gateway transaction index C Used to identify the unique components of transactions adjusted more than one time Required on for void transactions not for Mark for Captures MarkForCaptureResp Transaction Amount M 12 Echoesthe Amount passed in the request December 2006 Orbital Gateway Interface Specification Page 94 Field XML Parent Description Req Max Type Element M C O Char A N for definition of those error values MarkForCaptureResp Process Status AN MarkForC aptureResp Text message Text message associated with Proc Status value with Proc Status value The first element that should be checked to determine the RespTime MarkForC a ptureResp A o the transaction was processed by gateway Format hh24miss result of a request Itisthe only elementthat is
56. Type Flag BMLCustomerTypeFlag o Item Category BMLItemCategory o Customer Birth Date BMLCustomerBirthDate o Customer Social Security Number BMLCustomerSSN o Product Delivery Method BMLProductDeliveryType Optional o Customer Source IP BMLCustomerIP o Customer Email BMLCustomerEmail o Pre approval Invitation Number BMLPreapprovalInvitationNum o Promotional Code DBMLMerchantPromotionalCode o Customer Annual Income BMLCustomerAnnualIncome o Customer Resident Status BMLCustomerResidenceStatus o Customer Checking Account BMLCustomerCheckingAccount o Customer Saving Account BMLCustomerSavingsAccount December 2006 Orbital Gateway Interface Specification Page 29 NOTE Please contact your I Commerce Bill Me Later Integration Analyst during the requirements definition phase prior to development to determine required fields Cumencies US Dollar Only Other Virtual Terminal All of the functionality supported through this interface for Bill Me Later is additionally available through the Orbital Gateway Virtual Terminal Platforms The Orbital Gateway only supports the Bill Me Later method of payment through the Salem host platform BIN 000001 This method of payment is not supported on the PNS host BIN 00002 PINLess Debit Customers use their ATM Debit cards to pay for goods or services rather than cash check or credit card Debit transactions are always authorized on a real time basis with the ac
57. VV Passed Validation Information only no liability shift CAVV with ECI 7 C CAVV Not Validated Attempt Issuer did not retum a CAVV results code in the Authorization response CAVV Not Validated Authentication Issuerdid not retum a CAVV results code in the authorization response Invalid Security Data Issuer does not participate or 3 D Secure data not utilized HTTP Responses A few listing excluding specific Orbital Gateway HTTP responses and the descriptions can be found at http www w3 org Protocols rfc2616 rfc2616 txt The Gateway specific and common HTTP responses are Code Definition Status An HTTP Session was established with 200 Approved the Orbital Gateway Error conditions can still be retumed could not understand the request 403 Forbidden SSL Connection A Clear Text or unencrypted request Required was made to the Orbital Gateway All transactions must be SSL Encrypted to interface to Orbital within the maximum time allowed 412 IP Security Failure A non registered IP Address attempted to connectto the Orbital Gateway The HTIP connection was refused asa result 500 Intemal Server Error The serverencountered an unexpected condition which prevented it from fulfiling the request 502 Connection Emor The server while acting asa gateway Or proxy received an invalid response from the upstream server it accessed in attempting to fulfill the request Proc Status Tag Error Values Code
58. a Cardholder Ship TO State Salem Only Required for Amex Purchasing Card Data AMEXTranAdvAddn1 markForC apture Amex Purchasing Card Data Transaction Advice A Addendum 1 The TAA Record isused to further identify the purchase that is associated with the charge to the cardholder Itis also used in Purchasing Procurement card transactions to provide specific details about the transaction to the cardholder for tracking purposes TAA s should be as concise aspossible A TAA of Merchandise for example would not be acceptable M C O Char Type scription Req Max Meld PC DestAddress1 Amex Purchasing Card Data Cardholder Ship To Address line 1 Salem Only Required for Amex Purchasing Card Data AMEXTranAdvAddn2 markForC apture Amex Purchasing Card Data Transaction Advice A Addendum 2 Salem Only Required for Amex Purchasing Card Data AMEXTranAdvAddn3 markForC apture Amex Purchasing Card Data Transaction Advice A Addendum 3 Salem Only Required for Amex Purchasing Card Data AMEXTranAdvAddn4 markForC apture Amex Purchasing Card Data Transaction Advice A Addendum 4 Salem Only Required for Amex Purchasing Card Data December 2006 Orbital Gateway Interface Specification Page 87 XML Name XML Parent Char Type Element A N PC3FreightAmt markForC apture Purchase Card Level 3 freight amount for shipment 12 N Total freight or shipping and handling charges Implied decimal markForC
59. a debit C Item extended amount isa credit Required for Purchasing Card 3 for PNS BIN 00002 Merchants Purchase Card level 3 Line Item Detail Bement Tax Rate Tax rate applied for this item Implied decimal of 3asa percentage Ex Interest rate of 6 25 should be sent as 06250 Required for Purchasing Card 3 December 2006 Orbital Gateway Interface Specification Page 91 XML Name PC 3Dtllinetot PC3DUCommCd PC 3DUUnitC ost XML Parent Element PC 3Lineltem PC 3Lineltem PC 3Lineltem PC 3Lineltem Description Purchase Card level 3 Line Item Detail Hement Line Item Total For PNS customers Thisfield must equal the Unit Cost PC 3DtlUO M multiplied by the quantity PC3DtlQty less any discounts PC 3DtlDisc If it does not then this transaction will receive an eror Additionally the sum of all the Line Item totals i e the sum of all these fields cannot exceed the transaction amount lt Amount gt submitted for this order Implied decimal Cannot be all zeros Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Discount Amount for Line Item Amount of the discount applied to the line item Implied decimal Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Hement Commodity Code for Line Item The commodity code used to classify the item purchased Required for Visa Should not be sent for MasterCard Purchase Card level 3 Li
60. actional requests December 2006 Orbital Gateway Interface Specification Page 102 XML Label CustomerRefNum CustomerAddress1 CustomerAddress2 XML Parent Tag Profile Profile Profile Field Req Max Type Description M C O Char A N Sets the C ustomer Reference Number that will be used to C 22 A utilize a Customer Profile on all future Orders Mandatory if Customer Profile Action Type Read Update or Delete Or Create and the Customer Profile Numbergeneration option S Use CustomerRefNum Element Keys f CustomerProfileFromO rderind A the Customer Reference Number will be defined by the Gateway and any value passed in this element will be ignored Given that this value can be the same asthe Order Number the valid charactersforthis field follow the same convention asthe Order ID element Those valid charactersare abcdefghijkimnop qrstuvwxyzA BC DEFG HIJ KLM NOPQRST UVWXYZ0123456789 9 amp and a space character However the space charactercannot be the leading character This value may not be changed through a Profile Update action Cardholder Billing Address line 1 Optional if Customer Profile Action Type Create or Update This is the equivalent to the lt AVSaddress1 gt element used on transactional requests Cardholder Billing Address line 2 Optional if Customer Profile Action Type Create or Update This is the equivalent to the lt AVSaddress2 gt element used on transact
61. ailure o Ifan IP is registered but the client presents an MID that has NOT been associated with the originating IP the Orbital Gateway will return the following error HTTP 200 with a ProcStatus of 9717 XML Sc hema The Orbital Gateway accepts and returns XML documents using XML Schema Definition XSD that are defined by Chase Paymentech The latest XSD published for interfacing with the Orbital Gateway is PTI41 There are separate request and response XSD s Request PTI41 xsd amp Response PTIA41 xsd Note Versions PTI40 and above are not backward compatible with XML documents created in DTD version created in PTI34 and earlier All prior DTD versions are still supported but require the Mime Header to identify the version as PTI34 or lower Any new functionality exposed after PTI34 requires coding to the new XSD specification December 2006 Orbital Gateway Interface Specification Page 47 This allows Chase Paymentech requests and responses to be easily interpreted and manipulated using the w3c World Wide Web Consortium DOM Document Object Model or SAX Simple API for XML APIs MIME Header MIME Multipurpose Internet Mail Extensions is a mechanism for specifying and describing the format of Internet message bodies The Orbital Gateway supports both the HTTP 1 0 and HTTP 1 1 MIME Header specifications for describing the message payload along with other information that allows it to process the incoming transac
62. all Purchasing Card 3transactions If no value is submitted it will be default to the United States USA Required for Purchasing Card 3 See Table in Appendix A PC3ShipFromZip NewOrder Purchase Card Level 3 Ship from Zip The zip postal code ofthe location from which the goods are shipped Required for best Interchange rate and cannot be all zeros or nines December 2006 Orbital Gateway Interface Specification Page 75 XMLName XML Parent Element E o i 7 i Field Max Type Char A N 12 N Description Req M C O Purchase Card Level 3 Discount Amount from Order The total amount of discount applied to the transaction by the merchant Used by the merchant when a price break is given on an entire transaction ratherthan on unit prices Typically this is Shown asa crediton a detailed invoice Implied decimal Optional for Visa only Should not be sent for MasterCard Purchase Card Level 3 Total Amount of VATor other tax The total amount of VATorothertax included in this transaction Implied decimal Optional for Visa only Should not be sent for MasterCard Purchase Card Level 3 Rate of VATor other tax The total amount of VATorothertax expressed in percentage terms forthisline item 2 decimal implied Example 0001 196 Optional for Visa only Should not be sent for MasterCard Purchase Card Level 3 Altemate Tax ID TaxID numberforthe altemate taxassociated with this transaction Optional f
63. ame me Liquid pint 0 I T Liquid quart 0 946353 dm3 Long hundredweight G B 50 802345 kg Long ton GB US 1 0160469 t Orbital Gateway Interface Specification Page 147 December 2006 UOM Code Unit Name PCE LBR Pound GB US 0 45359237 kg O or eat eR lt lt WSD id Standard Em sone 68650095 M TOD Thousand cubic metres perda Troy pound US 373 242 g Orbital Gateway Interface Specification Page 148 UOM Code Unit Name E WEE December 2006 Orbital Gateway Interface Specification Page 149 Appendix B General Card Validation December 2006 There are three common edits that catch the greatest majority of bad card numbers e MOD 10 check digit e Credit card prefix check e Credit card length validation MOD 10 Check Digit The MOD 10 check digit calculation validates the credit card by calculating the last digit of the card number from all the other numbers in the card The last digit of a credit card can be calculated based on a calculation performed upon all the digits preceding it This operation is called a MOD 10 check digit routine Continued on next page Orbital Gateway Interface Specification Page 150 Use the following card for Example 5240159910151573 5240159910151 57 Start from the right and proceed to the left until all digits are multiplied by weight 7 2 14 sum 1 4 5 5 1 5 sum sum 5 5 10 1 2 2 sum sum 10 2 12 5 1 5 sum sum 12 5
64. andatory for Bill Me Later sale transactions BMLCustomerTypeHag NewOrder Customer Type Hag New or Existing Customer to the Merchant not Bill Me Later Valid Values N New E Existing Optional for Bill Me Later sale transactions BMLitemC ategory NewOrder Item Category Product Description Code assigned by Commerce Mandatory for Bill Me Later sale transactions BMLPreapprovalinvitationNum NewOrder Pre Approval Invitation Number Indicates whetherthe consumerhasbeen pre approved for Bill Me Later or not Pre approval from credit bureau should include the 16 digit pre approval number This will allow the pre approval to be matched with the first consumer order Intemal pre approval should include the leftmost digit asal No pre approval should include all zerosor be blank filled Optional for Bill Me Later sale transactions December 2006 Orbital Gateway Interface Specification Page 72 Field XML Name XML Parent Description Req Max Type Element Char BMLMerchantPromotionalCode NewOrder Merchant Promotional Code ee eee nacos 00 BMLC ustomerBirthDate NewOrder Customer Date of Birth YYYYMMDD Format Mandatory for Bill Me Later sale transactions BMLC ustomerSSN NewOrder Customer Social Security Number Eitherthe full 9 digit orlast 4 digits of the customer s Social Security Number Mandatory for Bill Me Later sale transactions BMLCustomerAnnualincome NewOrder Gross Household Annual Income Implied Decimal For example
65. arious possible states using the API messages and fields defined in this document December 2006 Orbital Gateway Interface Specification Page 8 Transaction Types The Chase Paymentech Orbital Gateway XML interface offers the following transaction types New Order Authorization Authorize the supplied information This transaction type should be used for deferred billing transactions Authorization Capture Authorize the supplied information and mark it as captured for next settlement cut This transaction should be used for immediate fulfillment Force Authorization Capture Force transactions will not generate new authorizations A good response simply indicates that the request has been properly formatted And the Orbital Gateway will settle the captured force at the next settlement event Refund Instruct the gateway to generate a refund credit based on the supplied information Complex Type Name New Order Request NewOrder New Order Response NewOrderResp Profile Transactions in New Order see more details in Profiles section The following are the Profile actions that can be executed in a New Order Transaction Using Profiles fora New Order One of the key transaction types is using a Profile to process a transaction Overriding Profile Data Almost any data set in the Profile can be overridden except card type during a transaction that is using the Profile For instance if a Profile include
66. as da 29 Ptocessme Requirements etn err snes tas a ra rts 29 December 2006 Orbital Gateway Interface Specification Page3 PIN Less pii ap PN 30 Introduction nai 30 Processing Requirements accent ias 31 Supported CU ads 32 Virtual Terminal eie ais 32 Soft Des cr pi tt cada 32 EOI na R ANE eN Aa 32 Soft Descriptor Support eiat Deor tentat ade ded 32 SALEM SUPPORT tacita 33 PINS SUPPORTS a a a NE 35 yid E E a E es 35 NOT TEULADA ti 35 A erre patieeietuti dede ue eie RS 36 Set p InfOrratlOD e sites detuvo eae ood e bU M ue Od due 36 Business Rules a abate 37 Processing Interface Description 45 OU o MO T aa a A G A A A A CANAR 45 Communication Protocol etes ee Peer ni a e a tia s 45 Posting toa URLs deiude do eoi Neg E 45 A Q 46 Secure Sockets Layer Implementation Required 46 Authentication s epi poro al unnan a 47 A agens uto uda pus ud nb cta AAE 47 MIME Header ee e ire ettet p a ERE 48 MIME Header Field Definition minis tert ice 48 KO A E 51 BUSINESS Uli Aia 51 Retry TIMIN Sii op aha anaes 52 XML Request Validation on Duplicate TRACE Numbers 52 Transaction Types 5uppokled ie inedit eerte 53 Retry Error Responses acie bet Wed sa 53 CONC i dritto is eiue so Ea etum re ees 53 Merchant TID oen SR RII n o E E tei ede 53 December 2006 Orbital Gateway Interface Specification Page 4 Transaction Time Out Response E
67. atabase Connection Problem Cannot acquire Resend Database Connection 9743 Pcard 3data wassent in parent split but is missing in current request 9744 If Alt Tax is sent Alt Tax ID is required Fix 9745 Three reasons could result in this error Fix Pcard 3 data can only be sent with MC and VI cards Pcard 3data cannot be sent on this request type Pcard 3data can only be sent with USor Canadian currency 9751 Line Item Count does not match the number of line items sent m 9752 Invalid debit indicator for Bin 000002 in index Must be D Fix or C 9753 Invalid Gross Net for Bin 000002 in index Must be Y or N Fix 9754 Amount hash enor negative total on line item data index 9755 Amount hash emoron line item data index Total s Fix Hash s 9756 Detail totals do not match requested amount 9757 Invalid Country Code 9758 Invalid Unit of Measure in index 9765 The field is missing invalid orhas exceeded the max length Orbital Gateway Interface Specification Page 136 December 2006 Code Description 9766 The Bill Me Later Card Type BL is Not Allowed with this transaction 9767 Bill Me Later Generic EnmorCode F 9768 Invalid Values Must be one ofthe following values XXX orempty 9769 BML Mandatory Field Customer Birth Date is missing for i New N Customer Type gt A ch e gt Fix ix Fix Fix 9793 PINLess Debit Invalid The field is missing invalid orhas Fix
68. ation Page 67 XML Name SDMerc hantName XML Parent Element NewOrder Description Req Max M C O Char Soft Descriptor Merc hant Name C 25 Conditionally required for Soft Descriptors The Merchant Name field should be what is most recognizable to the cardholder Company name ortrade name The actual length of this field isc onditionally tied to Host and the Size of the lt SDProductDescription gt field used Salem CREDIT Three options which conditionally affects the SDProductDescription see below o Max3 bytes o Max7 bytes o Max12 bytes ECP o Max15 bytes PNS Max25bytes Field Type A N A December 2006 Orbital Gateway Interface Specification Page 68 Field XML Name XML Parent Description Req Max Type Element Char A N SDProductDesc ription NewOrder Soft Descriptor Product Desc ription A Conditionally required for Soft Descriptors Providesan accurate product description Salem CREDIT If SDMerchantName 3 bytes then Max 18 bytes If SDMerchantName 7 bytes then Max 14 bytes If SDMerchantName 12 bytes then Max 9 bytes 10 bytes Max Thisfield will notshow on Cardholder statements for PNS Merchants NewOrder Soft Descriptor Merchant C ity Tag conditionally required for Soft Descriptors Merchant City forRetail Field required but should be null filled if any Soft Descriptor data is submitted December 2006 Orbital Gateway Interface Specification
69. being applied Purchase Card level 3 Line Item Detail Element Discount Indicator Indicates whether the amount if discounted Valid values Y Amount is discounted N Amount is not discounted If value Y and Discount Amount Field PC 3Disc Amt is Blank or Zero Filled Chase Paymentech will change this field indicatorto N before sending the data Optional for MasterCard only Should not be sent for Visa Purchase Card level 3 Line Item Detail Element Item Debit Credit Indicator Valid Values D Item extended amountisa debit C Item extended amountisa credit Required for Purchasing Card 3 for PNS BIN 00002 Merchants Field Type Max Char December 2006 Orbital Gateway Interface Specification New Order Response Elements Field XML Name XMLParent Description Req Max Type Element M C O Char A N tepore fequi XML Puerto ZEN NewOrderResp Response XML tag that defines the transaction as a New Order M N A N A response IndustryType NewOrderResp Defines the Industry type ofthe transaction M 2 A Thistag will retum null results Message Type NewOrderResp Defines the transaction New Order Transaction Type M 2 A Echoesthe Message Type passed in the request MerchantiD NewOrderResp Gateway merchantaccount number assigned by Chase M 12 N Paymentech Solutions Echoesthe account number passed in the request TerminallD NewOrderResp Merchant Teminal ID assigned by Chase Paymentech M 3 N Solutions E
70. ble Also referred to as Profile ID Customer Name Customer Email NOTE Only Available as a Profile Add or Update This XML element does not exist yet in the Authorization message set and cannot be sent as a part of an Auth Request profile Add as a result Address Information o Address1 o Address 2 o City o State o ZIP o Phone Amount Description This can be set in two ways Either by sending a specific description message or by setting the lt CustomerProfileOrderOveridelnd gt to populate the Comments tag which is the Order Description All Order fields This can be accomplished by setting the lt CustomerProfileOrderOveridelnd gt Payment Information o Card Type Credit Card e Card e Expiration Date ECP Salem Host Only BIN 000001 e DDA e R T e Account Type e Payment Delivery Method Switch Solo Salem Host Only BIN 000001 e Card e Expiration Date e Start Date e Issue Number December 2006 Orbital Gateway Interface Specification Page 41 Information NOT saved in a profile There are a number of items that will not be added to Profile regardless of how it is done This includes but is not limited to Purchasing Card Data Card Verification Number CVV2 CVC2 and CID This is because this information cannot be stored by card association regulation It must be requested from a cardholder on a transaction by transaction basis VbV and MasterCard SecureCode Data Updating Profi
71. ce Specification If the AAV is not submitted in Base 64 encoding or if the AAV is sent with a non eCommerce transaction a response code of 37 in the XML element lt RespCode gt will be returned Also if the Merchant has not tested and certified with Chase Paymentech to participate in MasterCard SecureCode and an AAV is sent with the e Commerce transaction a response code of 38 in the XML element lt RespCode gt will be returned which indicates the Merchant should contact their Chase Paymentech Representative to become SecureCode enabled Chase Paymentech will forward the transaction including the AAV in the MC authorization request The Issuer receives the authorization request validates the AAV and responds with an approval or a decline of the authorization If the AAV does not match the Issuer should decline the transaction MasterCard has not implemented any new decline codes for SecureCode Standard decline codes apply Merchant Requirements Merchant Plug in Software Install a Certified 3 D Secure Merchant Plug in Software Application or code to the 3 D Secure Protocol Verify that Merchant Plug in will provide the CAVV and or AAV in Base 64 encoding before sending to Chase Paymentech If not Merchant will need to convert to Base 64 before sending to Chase Paymentech Business Rules There are a number of business rules in terms of when a CAVV and or AAV should be presented on aged transaction reauthorizations split
72. choes the Terminal ID passed in the request CardBrand NewOrderResp Defines the Card Type Brand forthe Transaction M 2 A Echoesthe Card Type Brand passed in the request except fno CardBrand was sent in the request when optional such asVisa MasterCard the specific Card Brand mnemonic is retumed ForPINLess Debit transactions the request Card Brand is DP which isa generic PINLess mnemonic Howeverthe response Card Brand will be one of the three supported PINLess Debit Card Brands o NP NYCEPINIess Debit o PP Pulse PINless Debit o SP StarPINless Debit December 2006 Orbital Gateway Interface Specification Page 81 Field Type A N XML Name XMLParent Description Req Max Element M C O Char NewOrderResp Account Number M Value is conditionally retumed forapproved Bill Me Later transactions Other methods of payment will never retum the card number OrdenD NewOrderResp Merchant Defined Order Number M Echoes the Order Number passed in the request TxRefNum NewOrderResp Gateway transaction reference number M A unique value for each transaction which is required to adjust any transaction in the gateway such as Mark for Capture orvoid TxRefidx NewOrderResp Gateway transaction index M Used to identify the unique components of transactions adjusted more than one time Required on for void transactions not forMark for Captures ProcStatus NewOrderResp Process Status M The first element that should be checked
73. d Deposit platforms The PNS platform which is sometimes referred to as the Tandem or Tampa is primarily targeted to Retail and smaller customers The Salem platform sometimes referred to as the Stratus is primarily targeted to Card Not Present and larger customers Despite name both systems are collocated in both Tampa Florida and Salem New Hampshire Each Platform has unique processing features and since Orbital supports both not all features are available to all merchants The Gateway processes to both Platforms using identical transaction information as presented in this specification with the exception of any features that may only be available on one of the two Platforms Throughout this document there will be references to BIN 000001 Salem Platform or BIN 000002 PNS Platform Please contact your technical analyst or relationship manager if you are unsure which Platform your merchant account resides on Chase Paymentech Orbital Gateway Transaction Processing Model The Chase Paymentech Orbital Gateway described in this document operates on the basis that a merchant initially instructs the gateway to perform an operation on his her behalf Assuming that the initial operation is successful the gateway returns information that the merchant must use for all subsequent operations on the transaction in question The gateway manages the transaction state on behalf of the merchant The merchant moves the transaction between the v
74. d a fixed amount but a particular transaction was for a different amount it could be changed for that transaction by including a specific amount in the use profile request Adding Profiles during an Auth Given that in many circumstances the fist time a customer is setup an authorization needs to be performed the Orbital Gateway has extended the traditional Authorization transaction to enable adding a Profile in the same request Add profiles can be included with all New Order transactions types except Refunds December 2006 Orbital Gateway Interface Specification Page 9 HexCache Transactions As opposed to using the New Order transaction type for creating new FlexCache Transactions the FlexCache Element is used This supports the following FlexCache transactional capabilities Card Activation o Single Card Activation o Block Activation o Deactivate o Reactivate Add Value Authorization Redemption RedemptionCompletion Refund Balance Inquiry Void Reversal FlexCache Reversals are generated by sending a Reversal Void on the original request Please see reversal section below Complex Type Name FlexCache Request FlexCache HexCache Response FlexCacheResp Profile Transaction Types This transaction type allows for the following profile actions see Profiles section for details Add a Profile Delete a Profile Update a Profile Retrieve a profile and all its at
75. d above For example changing from an ECP transaction type to a Credit Card type the Profile Update message should Have the Card Type defined as Credit The Update message should include the Credit Card and Exp Date And it should send a Tilde for the four ECP data elements DDA R T Account Type and Payment Delivery Method December 2006 Orbital Gateway Interface Specification Page 42 Retrieving a Profile At any given time there may be a need to retrieve the data on an existing Profile There is a very simple Retrieve Profile transaction type available to perform this action Deleting a Profile Any Profile can be deleted at any time with a Delete Profile transaction At this stage even after a Profile has been deleted a Customer Profile Reference Number still may not be used again Using Profiles One of the key transaction types is using a Profile to process a transaction This is accomplished by Inserting the Customer Reference Number into one of the existing message types All data that can be pre populated by the Profile will be Any relevant data such as CVD for eCommerce transactions should be included in the request The transaction request should be completed per the normal spec in terms of which tags are mandatory If the data exists in the Profile and the Tag is mandatory simply null fill the tag This means that the correct XML Message type should be used based on the card type of
76. ded to the Salem PNS authorization response values they are available still via thistag The Customer Reference Number If Customer Profile Action Type Create and If CustomerProfileFro mO rderind S this field will echo the Customer Reference Number sent in the Profile Request Customer Billing Name Value from the Request Retumed Result Status of Profile Management Communic ates the successor failure of a Profile Management request 0 Success gt 0 An error condition see Appendix A for definition of the specific Profile Management enor values Verbose Text Description associated with ProfileProc Status Biller Reference Number PINLess Debit Only Echoed for Request Time the tansaction was processed by gateway Format hh24miss Req M C O C O Field Max Type Char A N 2 A 1 A 22 A A December 2006 Orbital Gateway Interface Specification Page 84 Mark for Capture of a previous authorization Request Elements Optional data should only be sent with the transaction to enhance the original authorization when eitherthe data wasnot sent in the original authorization orhas changed from the original authorization Please referto page 8 for further information on this subject When a split shipment is marked for capture the split amount forthe shipment should be included in the amount element forthis message The split transaction also results in the creation of a n
77. ds with a CAVV Response Code or lt CAVVRespCode gt within the XML response document as well as an approval or a decline of the authorization If the CAVV does not match the Issuer should decline the transaction Visa has not implemented any new decline codes for Verified by Visa The standard decline codes should apply NOTES A Merchant may not submit for authorization a purchase transaction that has failed authentication MasterCard SecureCode e MasterCard SecureCode is a solution designed to authenticate cardholders when paying online SecureCode offers a mechanism for securing the Internet channel by strongly authenticating the cardholder at the point of interaction by providing a unique transaction specific token that provides December 2006 Orbital Gateway Interface Specification Page 16 evidence that the cardholder originated the transaction SecureCode uses MasterCard s Universal Cardholder Authentication Field UCAF infrastructure to communicate the authentication information among the cardholder Issuer merchant and Acquirer e MasterCard SecureCode supports the 3 D Secure Protocol same as Verified by Visa MasterCard SecureCode requires merchants to install a 3 D Secure v1 0 2 compliant Merchant Server Plug in MPI software Transaction Flow The cardholder shops at a participating SecureCode Internet Merchant with no changes to the shopping or checkout The cardholder selects the merchandise to be purchased and
78. e enrolled in Verified by Visa and the Issuer authenticates the cardholder the Issuer is not permitted to submit a chargeback for unauthorized usage disputes reason codes 23 61 75 and 83 Either the Issuer ACS or Visa may designate excluded transactions however the Visa Directory Server will over ride excluded responses from an Issuer ACS if the BINs are not also designated as excluded BINs in the Visa Directory The designation of BINs as Commercial or anonymous Prepaid Cards must be consistent with VisaNet 2 Transactions conducted in new channels such as mobile or wireless devices December 2006 Orbital Gateway Interface Specification Page 19 Merchants named in the Global Merchant Chargeback Monitoring Program are not eligible for Chargeback protection for attempted authentications during the time that they are required to participate in the program and three months thereafter Visa will work with Acquirers to ensure compliance with this requirement There are no additional steps for Issuers regarding this provision Purchasing Card Introduction The Orbital Gateway supports the processing of procurement cards by fully supporting the enhanced data required by Visa and MasterCard for both Level 2 and Level 3 data Additionally for American Express the Orbital Gateway for Salem customers supports Level 2 and enhanced TAA Purchasing Cards with Level 3 data are typically used in a business to business environment providing
79. e components of transactions adjusted more than one time Required on for void transactions not for Mark for Captures OutstandingAmt Reversa lResp Remaining Non voided amount for partial Voids Sa N Proc Reversa IResp Process Status A The first element that should be checked to determine the result of a request Itisthe only element that is retumed in all response scenarios It identifies whether transactions have successfully passed all of the Gateway edit checks 0 Success All other values constitute an enor condition See appendix for definition of those error values December 2006 Orbital Gateway Interface Specification Page 98 Field XML Parent Description Req Max Type Element M C O Char A N StatusMsg Reversa IResp Text message associated with Proc Status value RespTime Reversa lResp Time the transaction was processed by gateway M N Format hh24miss December 2006 Orbital Gateway Interface Specification Page 99 End of Day Request Elements Thistransaction type will cause all Marked for Capture Transactions Sales and Refunds to be submitted for Clearing Batch Request Elements From an End of Day perspective a merchant may be configured in one of two wayson the Chase Paymentech Intemet Gateway Auto settle or Merchant initiated settlement Merchant s configured in auto settle mode can ignore the message types defined in this section Field Req Max Type XMLParentTag Description M
80. eCode Initial SecureCode authorization requests with AAV s older than 30 calendar days may be declined by the Issuer Recurring Transactions When a participating Merchant offers services of an ongoing nature to a cardholder for whom the cardholder pays on a recurring basis for example insurance premiums subscriptions Internet service provider fees membership fees tuition or utility charges the cardholder payments are considered recurring payments If the first payment originated as an Electronic Commerce Transaction via the Internet it must be submitted with the appropriate Electronic Commerce Indicator ECI value including Verified by Visa or MasterCard Secure Code authentication data CAVV or AAV respectively if applicable All subsequent payments must be submitted as Recurring transactions see Orbital Gateway Interface Specification and Message Templates documents The merchant must not store and submit the CAVV with any subsequent transaction Currencies Supported All Currencies Chargeback Liability Sift Exc lusions Verified by Visa There are certain exclusions from the Chargeback provisions related to attempted authentications They are 1 All Visa Commercial Cards Visa Business Visa Purchasing and Visa Corporate Cards anonymous Prepaid Cards such as gift cards and transactions from new channels such s mobile devices are excluded from chargeback protections for attempted authentications If these cards ar
81. ecification Page 38 Customer Reference Number hierarchy setup and usage As stated earlier Profiles can be created at Merchant ID Level or at the Chain level If a MID is configured to use Profiles at a Chain ID level any profiles setup by any Merchant ID are available to be used by any other Merchant ID s tied to that chain However if the MID is setup to manage Profiles at the merchant level any Profile setup by that Merchant ID can only be used by that Merchant ID For example Let sassume there is a single customer with two Merchant ID s on the Orbital Gateway 11111 and 222222 These two merchant ID s are tied to the same Chain ID 333333 Merchant ID 111111 sets up a new customer profile ABC If both Merchant ID 111111 and Merchant ID 222222 are setup to manage Profiles at a chain level then Merchant ID 222222 will be able to use profile ABC If either one of them is not the Merchant ID 222222 will not be able to use profile ABC Notes All Profile Setups are performed at a Merchant ID So this cross Chain ID sharing can only be facilitated via Orbital Setup In addition given that all setup and usage of Profile ID s is done using a specific Merchant ID there is requirement that the Chain ID be known to take advantage if this feature As long as all the Merchant ID s are properly linked to the same chain it will simply work If the Merchant ID s are not correctly mapped to the same Chain ID Merchant ID
82. em Sending the Merchant Descriptor record will not alter the descriptor on the accountholder s statement The purpose of this document is intended to outline how a developer can code to take advantage of this method of payment within the Orbital Gateway both in terms of the message layout and the business rules Virtual Terminal All of the functionality supported through this interface for European Direct Debit is additionally available through the Orbital Gateway Virtual Terminal Platforms The Orbital Gateway only supports the European Direct Debit method of payment through the Salem host platform BIN 000001 This method of payment is not supported on the PNS host BIN 00002 December 2006 Orbital Gateway Interface Specification Page 23 HexCache The Orbital Gateway supports Chase Paymentech s proprietary Stored Value Card product called FlexCache for both Salem and PNS customers See the FlexCache Message Specification for more detail Transaction Types This section defines all the FlexCache transaction types supported by the Orbital Gateway Card Activation Transaction Types The following is a list and description of the Card Activation transaction types Activate This transaction is used to activate one individual card for the first time Merchants processing to the PNS Host can process Prior Activation Transactions by additionally passing the correct prior approval code If the valid Prior Approval code is n
83. ember 2006 Orbital Gateway Interface Specification Page 131 Not applicable non Visa CVV2RespC ode Tag Values Code CVV2 CVC2 Discover CID Description M CVV Match CVV No match l BE Not processed Should have been present Unsupported by issuer FEN Invalid EG Invalid Y Notapplicable non Visa CAVVRespC ode Tag Values Code CAVV Description CAVV Not Present CAVV Not Validated due to eroneous data submitted CAVV Failed Validation Authentication Transaction CAVV Passed Validation Authentication Transaction CAVV Attempt a 3 D Secure authentication value of 7 from the Issuer ACS indicates authentication was attempted Determined that the issuer ACS generated this value from the use of Visa CAVV keyl s Visa generated this value from the use of CAVV key s Reserved for Future Use NOTUSED CAVV Not Validated Issuer not participating in CAVV validation CAVV Failed Validation Attempt CAVV generated with Visa Key CAVV Passed Validation Attempt CAVV generated with Visa Key CAVV Failed Validation Attempt a 3 D Secure authentication value of 7 from Visa s ACS indicates that an authentication attempt was performed Determined that December 2006 Orbital Gateway Interface Specification Page 132 CAVV Failed Validation Attempt CAVV generated with Visa Key Issuer ACS unavailable CAVV Passed Validation Attempt CAVV generated with Visa Key Issuer ACS unavailable CA
84. ement or usage as they do to any card number viewing in the VT previously fa User s permission allows the viewing of the credit card number then during usage or management that User will be allowed to see any credit card number whether maintaining a profile or using it Conversely if that User s permission level does not allow the number to be viewed then it cannot be viewed whether they have the right to maintain a profile or use it However the card can be changed or updated regardless of masking o Access Levels All existing access levels will not be impacted regardless of Profile user rights For instance if a User cannot submit credits they will not be able to submit credits using Profiles Business Rules How it works Profile Management is a very simple product The first step is to create a Profile This can be done in two different fashions 1 Adding a Profile as a distinct action 2 Oradding Profile as a part of an authorization request Once that Profile exists it can be utilized to complete a sale or refund with any of the data elements stored in the profile Additionally any part of the Profile can be overridden during the subsequent transactions Finally the Profile can be updated or even deleted at any point Customer Referenc e Number Options The Customer Reference Number lt CustomerRefNum gt in the schema or Profile Number in the Virtual Terminal is the referential data element to a Profile
85. ength of the Response M XML Document Content transfer encoding Defines the encoding of the associated XML M document Request number Should always be 1 M Document type Defines whether this is a Request or M Response This value will always be Response Resend Count Identifies the number of times a response is C returned See below section for more definition Last Retry Attempt Identifies the last previous retry response C sent See below section for more definition The format of the data is YYYYMMDDhh 24 mmss HTIP Responses When successfully interacting with the Orbital Gateway the HTTP value returned will always be a 200 response such as HTTP 1 0 200 OK All other responses indicate some sort of connection problem Please refer to REC 2616 http www w3 org Protocols rfc2616 rfc2616 txt for more definition of the variance HTTP responses that could be returned and their meaning A HTTP 200 response in and of itself does not constitute a good response It simply means that the connection has successfully been established with the December 2006 Orbital Gateway Interface Specification Page 50 Retry Logic Orbital Gateway Please read the response handling sections for full response interpretation definition Resend Count The purpose of this MIME Header Response Field is to expose how frequently the Gateway has returned a particular response to your system The first time a transaction is submitted to our sy
86. equest generation The next two sections define how the system manages that security Secure Sockets Layer Implementation Required The XML gateway URL must be accessed using the https protocol so that private information is transferred securely This requires the client to use a SSL implementation There are SSL implementations available for most programming languages It is the client s responsibility to gain the necessary expertise and technology to properly open a secure channel to the gateway unless the client uses of one Chase Paymentech s available SDK s Interfacing to the Orbital Gateway using SSL does not require the client to have a certificate The Orbital Gateway uses a non authenticated SSL session meaning the client is not authenticated using a digital certificate as a component of the SSL negotiation See below section for how Chase Paymentech authenticates client traffic Non SSL postings should never be made across a network that is external or not totally controlled and secure If a clear text request is made to one of the Orbital Gateway URL s it will return an error condition an HTTP 403 error with the accompanying XML payload containing a ProcStatus 20403 error December 2006 Orbital Gateway Interface Specification Page 46 Authentic ation The Orbital Gateway uses source IP authentication to authenticate the request generation What this means from a client implementation is as follows e When processing
87. erences e The value for these cards is 4 digits and is printed not embossed on the front of all cards On the American Express card it appears on the right border of the card however on Optima cards it appears on the left border of the card e In situations where the CID value is invalid American Express could respond with an authorization decline message American Express will respond with a separate CID response code e To process American Express CID the merchant must contact their American Express Client Manager to have their American Express service establishment numbers flagged to accept the Amex CID value American Express will not provide validation of the CID value if the merchant s Service Establishment SE is not enabled HexCache Stored Value Application The Chase Paymentech FlexCache program supports CVD2 Card Verification Data 2 which is also known as a PIN as an optional feature determined by the merchant The four digit value may be imprinted on the back of the stored value card and used to facilitate a secure Card Not Present transaction when the consumer wishes to use a FlexCache card as their method of payment Guidelines for populating Card Security Fields The Card Security Fields are called lt CardSecVallnd gt amp lt CardSecVal gt Verified by Visa MasterCard SecureCode Programs Verified by Visa and MasterCard SecureCode are both solutions designed to authenticate cardholders when paying online
88. ew order for the balance left over from the original authorization and adjustments as required to the original authorization Upon marking a portion orthe remainder of the split transaction the system will automatically attempt to obtain a new authorization forthe new order when it is settled Req Max Field XML Name XML Parent M C O Char Type Element SC feni XML Paene Rg i AS V OrdenD markForC apture Merchant Defined Order Number M 22 Should use the same OrdenD asthe original request Description markForC a pture Transaction Amount Keys Amount being captured It can be lessthan orequal to the original authorization Anything lessthan will create a split transaction Implied decimal including those cumenciesthat are a zero exponent For example both 100 00 an exponent of 2 and 100 Yen an exponent of 0 should be sent as lt Amount gt 10000Amount gt See table formin maxamount foreach currency type markForC apture Defines the tax type Required for Purchasing Card Levelll Data 0 Not provided 1 Included 2 Non Taxable Not valid for Visa Purchasing Card Il qualification XML Parent Element markForC a pture Tax Amount for the purchase Required for Purchasing Card Level ll Data Implied decimal including those currenciesthat are a zero exponent M C O Char Type Description Req Max Field A N markForC apture Transaction Routing Definition Assigned by
89. eway eCommerce Mail Order and Recurring are all supported within Profiles The transaction in question should set the correct tags as identified in the XML Message Specification Currencies All currencies supported by the Orbital Gateway are supported as a part of Profiles Simply set the correct currency code and exponent on the transaction being processed Retry Logic Usage Retry Logic the function that allows transactions to be processed without risk of duplicating them will not be supported for Profile Management transactions In other words Adds Deletes Retrieves and Updates However if when performing a Profile Management transaction an unknown result occurs simply replay that transaction If the prior transaction was a success the second attempt will simply result in duplicate response which not cause any harm If the original request was not successful the second attempt will create the result desired While Retry is not supported for Profile Management transactions there is no harm in placing the Trace ID values associated with Retry Logic in the MIME Header of these request items In these circumstances the trace value will simply be ignored Note Using Profile during an Authorization Retry Logic is fully supported as defined the message specification December 2006 Orbital Gateway Interface Specification Page 44 Processing Interface Description Introduction The Processing Interface f
90. exceeded the max length 9794 PINLess Debit The PINLess Debit Card Type DP is Not Fix Allowed with s Transactions 9795 PINLess Debit The PINLess Debit Card Type DP is Only Fix Allowed with s Transactions 9796 PINLess Debit The PINLess Debit Card Type DP must be Fix sent with Industry Type of 9 5 9797 PINLess Debit Card Number Not Eligible for PINLess Debit Processing 10005 Eror communicating with the host 10011 Response timed out waiting for Authorization Host Resend 10096 Invalid Card Number 10204 Invalid AVS AP Code 10332 Invalid Message Format Transaction wasflagged asan eCommerce Industry Type but No ECOrderNum was sent 10333 The ECOrderNum orMailOrderNum wasall Zero sorAIl paces These are not valid 10334 Invalid Card Number 10336 Transaction Amount to Large 10337 Transaction Amount to Small 10349 Host eFalcon check requested from PNS BIN 000002 This Fix functionality is not supported on this platform 11001 Locked Down Unable to Perform a Partial Void on Industry Fix Type RE F F F Fix Fix ix ix Fix Fix ix Fix Fix All GATEWAY SYSTEM ERROR CONDITIO NS Resend other This encompasses various processing errors 10000 11000 Profile Errors 9550 Invalid Customer Reference Number From Order Indicator Fix 9551 Invalid Customer Reference Number Fix System Failure Unable To Perform Customer Profile pops Request at This Time on 553 9555 5 9556 5 9557 5 9558
91. face Specification Page 60 XML Name AVScountryCode XML Parent Element 7 Description Cardholder Billing State Should not include any of the following characters types V I Required for Bill Me Latersale transactions Cardholder Billing Phone Number AAAEEENNNNXXXX where AAA Area Code EEE Exchange NNNN Number XXXX Extension Required for Bill Me Latersale transactions Cardholder Billing Name Required for Bill Me Later sale transactions and all Electronic Check Transactions Cardholder Billing Address Country Code Required if processing a U K based Address Valid values US United States CA Canada GB Great Britain UK United Kingdom _ Blank forall other countries Required for Bill Me Latersale transactions Bill Me Later Cardholder Destination Address Zp Code AllAVS Requests must minimally include the 5 digit Zip Code If sending Zp Code 4 please separate with a Required for Bill Me Latersale transactions December 2006 Orbital Gateway Interface Specification XML Name AVSDestaddress1 AVSDestaddress2 AVSDeststate XML Parent Element Description Req Max Char Bill Me Later Cardholder Destination Address line 1 Should not include any of the following characters types V I Required for Bill Me Latersale transactions Bill Me Later Cardholder Destination Address Line 2 Should not include any of the following characters types V I Op
92. g Profile And it must be null filled to not override the expiration date that might be set in the profile December 2006 Orbital Gateway Interface Specification Page 43 As such if an Expiration date is saved in a Profile and the desire is to override that but submit nothing because the new expiration date is unknown the transaction should use one of the other two supported mechanisms for supporting unknown expirations dates Send fourspaces Exp lt Exp gt Zero fill the XML Element lt Exp gt 0000 lt Exp gt Transaction Types Profiles may be used on Authorization Authorization Capture Prior Authorizations and Refund transactions It is not functional or necessary for Voids Mark for Capture or End of Day transactions Mark for Capture Transactions While the correct Credit Card or Switch Solo Mark for Capture MFC transaction never really required the card number from a business perspective the Orbital Gateway DTD mandated the presence of the XML element So many customers are either sending the actual credit card number a dummy number or null filling this tag Effective with the release of Profile Management the Orbital Gateway has corrected this design and no longer mandates this tag to be a part of the MFC request This was done to ensure that a customer using a Profile could complete a MFC without having to include this tag Industry Types All the Industry Types are supported by the Orbital Gat
93. he system including Re ource On Line Any questions about the available reports should be directed to your account manager The Virtual Terminal should not be used for FlexCache reconciliation Bill Me Later Introduction Bill Me Later is an innovative and secure payment solution for card not present merchants The Bill Me Later method of payment is a non plastic issued credit vehicle that manages the consumer payment function by providing a December 2006 Orbital Gateway Interface Specification Page 28 transactional credit decision in lieu of the standard predetermined credit line and associated authorization process Bill Me Later allows consumers to make online mail order purchases without inputting credit card information How it works Using proprietary credit scoring and fraud detection capabilities Commerce screens each Bill Me Later transaction in real time instantly decisioning all Bill Me Later requests made by customers Processing Requirements Merchants must contract with Commerce for acceptance of Bill Me Later The Orbital Gateway enforces the following data requirements for sale authorization authorization capture transaction types Required o Account Number o Bill To Address see standard AVS elements o Ship To Address see AVSDest elements o Shipping Cost BMLShippingCost o Terms and Conditions Version BMLTNCVersion o Customer Registration Date BMLCustomerRegistrationDate o Customer
94. i a X Orbital Gateway Interface Specification Page 137 December 2006 Code Description Action 9559 9560 9561 9562 9563 9564 9565 9566 9567 9568 9569 9570 9571 9572 9573 9574 9575 9576 9577 9578 9579 9580 9581 9582 9583 9584 9585 9587 9588 9589 9710 9711 9712 9713 9714 9715 ImeiEma f Rx F Invalid ECP Account Type Indicator Invalid ECP Account Route Invalid ECP Bank Payment Delivery Method Invalid ECP Account DDA Invalid Switch Solo Start Date F Invalid Account Expire Date F Invalid Switch Solo Issue Number Invalid Order Ovenide Indicator Fix Merchant Bin combination is not allowed to perform Call profile transactions Cannot process profile for Cust Ref Num and MID Call combination A database error has occurred ix ix ix ix ix ix i ix ix ix ix i ix ix i ix ix i ix i i Fix Num and MID orissue number is required i ix ix Merchant Bin is not active ix ix Cannot process profile Profile does not exist for Cust Ref Num and MID Missing Electronic Check Account Information F Missing Credit Card Account Information ix Auto Gen Cust Ref Num Eror W Unable to Perform Profile Transaction The Associated Call Transaction Failed Unable to Determine Profile Action from Auth Request Cannot Create Profile A Customer Profile Na me is Required Pty Ems EA F ix ix Message expired during retr
95. ic processing rules associated with PINLess Debit the Orbital Gateway enforces specific behavior as it relates to PINLess Debit Only allow Authorization Capture transaction types are allowed This means o No Auth Only future fulfillment transactions o No Mark for Capture o No Splits o No voids o No refunds All Merchant ID s Transaction Divisions enabled for PINLess Debit must have auto settle enabled PINLess Debit BIN Ranges are every dynamic Chase Paymentech makes PINLess Debit BIN files available on a regular basis to determine which cards are eligible to participate on each transaction Additionally the Orbital Gateway imports and stores the most up to date PINLess Card ranges Ifa card is submitted as PINLess Debit as identified by the required card mnemonic and it is not in an eligible card range a ProcStatus error code of 9717 PINLess Debit Card Number Not Eligible for PINLess Debit Processing Optionally a merchant can retrieve their own Debit BIN files Please discuss with your account manager the available options A new Industry type of IVR IV has been added but is only allowed PINLess Debit method of payment Data set required to submit a PINLess Debit transaction is o IndustryType IVR or eCommerce Only MessageType AC only BIN 000001 only Merchant ID TerminalID 001 only CardBrand DP Account Number Expiration Date null Currency Code 840 US Dollar only Currency Expone
96. id HexPartialRedemptionind flexCache Triggerto allow an approval fora Redemption Completion 1 HexAction if the available balance is less than the StartAc countNum flexCache Defines the first Card Number in a Block Activation Sequence ActivationCount flexCache Defines the number of Cards in addition to the first Card Number in the sequence The maximum number of cardsthat can be activated atone time is 100 As such the maximum number allowed to be sent in this field is 99 TxRefNum flexCache Gateway transaction reference number A unique value for each transaction which is required to adjust any transaction in the gateway such as Mark for Capture or void requested amount December 2006 Orbital Gateway Interface Specification Page 116 HexEmployeeNumber PriorAuthID XML Parent Element flexcache flexcache Field Description Req Max Type M C O Char A N Employee Number 15 A Optionally available field to pass an Employee Numberon the transaction This will appear in FlexCache generated not Orbital Gateway reports Only supported for PNS Interfaces Prior Authorization Code If a priorauthorization code is available It should be sent in thistag This reducesthe risk of chargebacks Thiselement should not be included on an ECP transaction Thisshould only be sent if the transType F or FC Only supported for PNS Interfaces December 2006 Orbital Gateway Interface Specification Page 117 HexCache
97. idation for Purchasing Card 2 or 3 for Salem customers BIN Ranges The BIN range assigned by the card associations can identify purchasing cards BIN ranges are subject to change at the discretion of the card associations Processing Purchasing Card 2 or 3 data can be sent either in the original auth via an Auth or Auth Capture or it can be appended to the authorization via the Mark for Capture request if it was not originally supplied in the authorization request There are different rules for adding and adjusting Purchasing Card data via the Mark for Capture based on whether it is simply level 2 data or if it is level 3 data MFC Adjustment of Level 2 Data When processing Purchasing Card level 2 data the additional data can be included in either the Auth and adjusted or added altogether via the Mark for capture transaction The following scenarios describe the optional behavior If the Purchasing data is submitted on the Authorization o No purchasing Card data is submitted on a Mark for Capture whether full or partial amount The gateway will submit at settlement the purchasing card data presented on the authorization o Purchasing Card Data is submitted on the Mark for Capture MFC and the MFC is for The full amount The Purchasing Card data submitted on the MFC will override the data submitted on the Auth Partial Amount Where the amount of the MFC is less than the auth and a split transaction is generated
98. ion will be a distinct transaction with a distinct Transaction Reference Number from the original Authorization All the relevant details of the second request will be returned in the response Redemption Completion As stated above a redemption completion is to complete an authorization A Transaction Reference Number lt TxRefNum gt is returned which references the original transaction Assuming the authorization approved a then a Redemption Completion FlexAction is submitted and additionally including the December 2006 Orbital Gateway Interface Specification Page 26 original auths transaction reference number and the amount to be settled this amount can be equal to or less than the original authorization When an amount is less than original amount the entire original balance on hold is removed and the new amount redeemed from the card As stated above this functionality is only available Merchants processing through the Salem Platform Redemption As opposed to an Authorization followed by a Redemption Completion a Redemption transaction is the mechanism to perform an immediate redemption Once completed Redemptions can only be reversed Merchants processing to the PNS Host can process Prior Redemption Transactions by additionally passing the correct prior approval code If the valid Prior Approval code is not passed it will be treated as a new Redemption request Salem Merchants attempting to process a Prior Redempt
99. ion will receive an error response Refund This transaction type is for initiating refunds to a FlexCache card It is essentially the same as an Add Value transaction Reversals All transaction types excluding Balance Inquiries can be reversed thus returning a transaction to the state it was in prior to the action being reversed There are two restrictions as it relates to processing Reversals For Salem customers the reversal must be performed within seven 7 days of the original transaction For PNS based customers the reversal must be performed before the next batch close Batch closes for FlexCache are usually automatically at 5 00am EST regardless of what the Auto settle time is on the Gateway For all customers another action has not occurred that no longer makes the reversal possible o For example an active card can no longer have an activation reversed once a transaction has been processed The card can only be deactivated at that point if desired A reversal is accomplished by simply processing a Void FlexAction type using the merchant information and the Transaction reference number of the original This is true of all reversal transaction types Unlike other transactions the Complex Type Reversal is not used for FlexCache Void reversal actions The response on a Reversal will provide the same information as any other response Current Balance Previous Balance Response Codes etc In addition it
100. ional requests December 2006 Orbital Gateway Interface Specification Page 103 XML Label XML Parent Tag o o CustomerZIP Profile _ Description Cardholder Billing City Optional if Customer Profile Action Type Create or Update This is the equivalent to the lt AVScity gt element used on transactional requests Cardholder Billing State This is the equivalent to the lt AVSstate gt element used on transactional requests Optional if Customer Profile Action Type Create or Update Cardholder Billing Address Zip Code AllAVS requests must minimally include the 5 digit Zp Code Ifsending Zp Code 4 please separate with a Conditionally required if Customer Profile Action Type Create This is the equivalent to the lt AVSzip gt element used on transactional requests Cardholder Email Optional if Customer Profile Action Type Create or Update There is no equivalent to this element available on transactional requests December 2006 Orbital Gateway Interface Specification Page 104 XML Label CustomerPhone CustomerProfileAction CustomerProfileO rderOverridelnd XML Parent Tag Profile Profile Profile Field Req Max Type Description M C O Char A N Cardholder Telephone Number A Format ZAAAEEENNNNXXXX where AAA Area Code EEE Exchange NNNN Number XXXX EXTENSION OPTIONAL IF CUSTOMER PROHLE ACTION TYPE CREATE OR UPDATE THIS IS THE EQUIVALE
101. ish an inline web page session with the Issuer ACS The window displays Issuer specific and MasterCard branding transaction details including Merchant name and amount and prompts the cardholder to enter their SecureCode e g password If the password is entered correctly the transaction continues The cardholder is allowed a limited number of password attempts typically 3 to 5 as defined by the Issuer ACS If unable to correctly enter the password the cardholder may access the password hint that was established during the registration If the password is incorrectly entered more times than the Issuer limit a failed Payer Authentication Response is returned to the Merchant The Issuer ACS retrieves the authentication information and compares it against the data that was registered during the initial cardholder registration process If the data matches a success page is presented to the cardholder and the Issuer ACS sends a message through the browser to the Merchant providing evidence of cardholder authentication including a 28 byte Account AAV This AAV is December 2006 Orbital Gateway Interface Specification Page 17 generated cryptographically using Issuer specific secret keys that are synchronized with keys at the Issuer s authorization platform Merchant Submission of AAV Data The merchant will then send the transaction to Chase Paymentech along with the 28 byte AAV in Base 64 encoding within the Orbital Gateway XML Interfa
102. k null filled and the DebitC a rd IsueNum field must be populated December 2006 Orbital Gateway Interface Specification Page 58 Field XML Name XML Parent Description Req Max Type Element M C O Char A N DebitCardStartDate NewOrder Switch Solo card start date C N Format MMYY Tag Mandatory for Switch Solo NOTE The card start date should be submitted only when the card doesnot have an Issue number If the card displa ys ONLY a Start Date and no Issue Number the DebitC ardStartDate field must be blank null filled If the card displays both a Start Date and an Issue Number this field should be left blank and the DebitC ard IssueNum field must be populated BCRiNum NewOrder Bank routing and transit number for the customer Conditionally required for Electronic Check processing NOTE All US Bank Routing Numbers are 9 digits Al Canadian Bank Routing Numbers are 8 Digits CheckDDA NewO BEC Customer DDA account Endo ume A et Endo ume required forElectronic Check processing BankAccountlype NewOrder Defines the deposit accounttype Conditionally required for Electronic Check processing C Consumer Checking US or Canadian S Consumer Savings US Only X Commercial Checking USOnly ECPAuthMethod NewOrder Defines the ECP Authorization method Code used to identify the method used by consumers to authorize debitsto theiraccounts If no value submitted we will default this value Valid Values W Written
103. l Gateway Interface Specification Page 54 Transaction Management Messages New Order Request Elements Auth Auth Capture Prior Auth Ca pture and Refunds Field XML Name XML Parent Description Req Max Type Element M C O Char A N CON EEE EE IndustyType NewOrder Defines the Industry type of the transaction MO Mail Ordertransaction RC Recuning Payment 7a eCommerce transaction IVR PINLess Debit Only Message Type NewOrder Defines the transaction New Order Transaction Type A Authorization request AC Authorization and Mark for Capture FC Force Capture request R Refund request NewOrder Transaction Routing Definition Assigned by Chase Paymentech 000001 Salem 000002 PNS XML Na me XML Parent Element MerchantiD NewOrder NewOrder NewOrder NewOrder Description Gateway merchant account number assigned by Chase Paymentech This ac count number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID Merchant Terminal ID assigned by Chase Paymentech All Salem Terminal IDs at present must be 001 PNS Terminal ID s can be from 001 999 Most are 001 Defines the Card Type Brand for the Transaction See attached table Required for SW Switch Solo ED European Direct Debit EC Electronic Check BL Bill Me Later DP PINLess Debit Generic Value Used in Requests Card Number identifying
104. le Resp Transaction Routing Definition eee SBMNN A eee mE N EET CustomerRefNum profile Re sp Customer Reference Number CustomerProfileAction profile Resp Defines the Customer Profile action requested E NJ N gt CustomerProfile Message profile Resp Verbose Text Description associated with ProfileProc Status ERAEN CustomerAddress1 profile Resp Cardholder Billing Address line 1 CustomerAddress2 profileResp Cardholder Billing Address line 2 a profile Resp Cardholder Billing City CustomerState ustomerState profi profileResp Resp Cardholder Cardholder Biling State State p Los leResp Cardholder Billing Address Zip Code A E 8 1 CustomerPhone profile Resp Cardholder Telephone Number Format ZAAAEEENNNNXXXX where AAA Area Code EEE Exchange NNNN Number XXXX EXTENSION gt gt l a December 2006 Orbital Gateway Interface Specification Page 111 Field Req Max Type XMLParentTag Description M C O Char A N CustomerProfileOrderOverridelnd profile Resp Defines if any Order Data can be pre populated from the Customer Reference Number CustomerRefNum NO No mapping to orderdata OI Use lt CustomerRefNum gt for OrdernD and ECOrderNum or MailO rderNum OD Use lt CustomerReferNum gt for Comments OA Use lt CustomerRefNum gt for OrderD and ECOrderNum or MailO rderNum and Comments OrderDefaultDesc OrderDefaultDescri
105. les Once a Profile has been added any information about a Profile can be updated except the Profile Keys which again includes the Customer Reference Number Merchant ID and BIN This can be accomplished by sending a Profile Update transaction Some important keys to performing an Update All Profile Update requests must include the correct Profile keys or an error message will be returned A list of the error messages can found in the appendix An update requires the Tags to be sent for both o The Data that should be updated o And for any fields that should be cleared To clear any legacy data the XML Tag is submitted with nothing but a Tilde See below example for performing this step lt CCExpireDate gt lt CCExpireDate gt For example if the Customer Profile included an amount and update was sent with the Amount Tag present but filled with a Tilde character the amount stored in the profile would be changed to null in the database If an XML tag is sent with a Null value such as lt CCExpireDate gt lt CCExpireDate gt it will be ignored as a part of the update process i e no update would occur on the CCExpireDate value from the example When changing Card Types such as from an ECP to a Credit Card what is required is o Send the XML tag representing the new card type o Submit the appropriate data for that card type o Null the old card type data elements using the Tilde process describe
106. ltiplied by the quantity PC 3DtlQty less any discounts PC3DtlDisc If it does not then thistransaction will receive an emor Additionally the sum of all the Line Item totals i e the sum of all these fields cannot exceed the transaction amount lt Amount gt submitted for this order Implied decimal Cannot be all zeros for either PNS or Salem Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Discount Amount for Line Item Amount of the discount applied to the line item Implied decimal Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Commodity Code for Line Item The commodity code used to classify the item purchased Required forVisa Should not be sent forMasterCard Purchase Card level 3 Line Item Detail Element Unit Cost of Item Purchased Unit Cost of the unit purchased Implied decimal of 4 Required for Purchasing Card 3 December 2006 Orbital Gateway Interface Specification Page 79 XMLName XML Parent Element Pc 3DUG rossNet PC 3Lineltem uM o i Description Req M C O Purchase Card level 3 Line Item Detail Element Gross Net Indicator Indicates whether tax amount is included in the item amount Valid values Y item amount includes tax amount N Item amount does not include tax amount Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Type of Tax Being Applied Type of tax
107. m Length 1 Maximum Length 16 As such Valid Values are from 1 9999999999999999 Submitting an invalid value will result in an XML Quick Response with a ProcStatus Code of 9714 Interface Version This MIME Header field is used by the Client to identify information about their implementation to assist Chase Paymentech in providing production support This information will be logged distinctly for research purposes An example of the usage of this filed would be any Third Party Software Provider should log December 2006 Orbital Gateway Interface Specification Page 49 their Software name and version number in this field such that Chase Paymentech knows how the interface is being managed A Merchant could place information about their development version and implementation language Please work with your Certification Analyst to best identify what values should be used in this field Response MIME Header Definition This may not be an all inclusive list of MIME Header response fields Do not code your system to support only these Field Definition M C HTTP See below section for more definition M Date Returns the Server Date and Tamp stamp for M example Fri 27 Oct 2000 20 29 58 GMT MIME Version Will always be 1 1 M Content type Defines the XML version number This will M be an echo of what is submitted in the request Content length This value defines the l
108. n Add Profile Request There are new response data elements that need to be interpreted to determine the success of this Add request Adding Profiles during an Auth Given that in many circumstances the fist time a customer is setup an authorization needs to be performed the Orbital Gateway has extended the traditional Authorization transaction to enable adding a Profile in the same request Any data included in the Authorization that can be saved as a part of the profile will be The minimum data to create a profile must be included or no profile will be created December 2006 Orbital Gateway Interface Specification Page 40 The result of the authorization is separate from the result of the profile add step As such an authorization can be successful and the Profile Add component can be an error on the same transaction and vice versa These results are mutually exclusive and should be interpreted from a response management process as such Add profiles can only be included with Auth Only Auth Capture and Prior Auth i e Force transactions It cannot be completed as a part of a Refund Void or Mark for Capture Information saved in a profile Whether a Profile is added via a Profile Add transaction or added via an authorization or updated later via a Profile Update transaction the following list of items defines what data elements can be saved as a part of a Profile Customer Reference Number Required and un edita
109. ne Item Detail Hement Unit Cost of Item Purchased Unit Cost of the unit purchased Implied decimal of 4 Required for Purchasing Card 3 Max Field Char Type A N December 2006 Orbital Gateway Interface Specification Page 92 Description Req Max Field XML Name XML Parent M C O Char Type Element A N PC 3Lineltem Purchase Card level 3 Line Item Detail Hement Gross Net C Indicator PC3DtGrossNet Indicates whethertax amount is included in the item amount Valid values Y 2 item amount includes tax amount N Item amount does not include tax amount Required for Purchasing Card 3 PC3Lineltem Purchase Card level 3 Line Item Detail Hement Type of Tax Being Applied PC3DtiTaxType Type of tax being applied PC 3Lineltem Purchase Card level 3 Line Item Detail Hement Discount Indicator PC 3DtiDisc Ind Indicates whetherthe a mount if discounted Valid values Y Amount is discounted N Amount is not discounted If value Y and Discount Amount Field PC 3Disc Amt is Blank or Zero Filed Chase Paymentech will change this field indicatorto N before sending the data Optional for MasterCard only Should not be sent for Visa December 2006 Orbital Gateway Interface Specification Page 93 Mark for Capture Response Elements Field XML Name XML Parent Description Req Max Type cid BUE LE A N Response NA RequiredXML
110. nt 2 only Order ID Amount Biller Reference Number 0070 1700 OF Qr 0 0 O Q9 Approved PINless Debit transactions may return a Blank or N A authorization code December 2006 Orbital Gateway Interface Specification Page 31 Supported Currencies U S Currency Virtual Terminal The Orbital Virtual will display and report PINLess debit transactions but it will not support e Creation of new PINless debit transactions are not supported because PINless Debit transactions are only supported via IVR or ECommerce channels e Adjustments of existing PINLess debit transactions Soft Desc riptors Introduction The Soft Descriptor Records are used to define the merchant name product description that will appear on the consumer s statement It allows the merchant greater flexibility in describing the consumer s purchase It is subject to issuer discretion whether this descriptor will be displayed on the cardholder statement Soft Desc riptor Support Support for Soft Descriptors is not globally available to all customers using the Orbital Gateway Salem BIN 000001 The Orbital Gateway supports Soft Descriptors into the Salem Host However o Prior Risk Department approval is required o The Merchant ID Terminal ID must be enabled for Soft Descriptors on the Orbital Gateway o Please contact you Chase Paymentech Representative PNS BIN 000002 The Orbital Gateway supports Soft Descriptors into the
111. nt ID must be configured to allow Profile functionality Any Merchant ID that is not configured to use Customer Profiles and attempts to process a Profile Action will receive an error A Profile Error Code of 9578 or Merchant Bin combination is not allowed to perform profile transactions will be received Customer Profile Hierarchy Support Each Merchant ID must be configured to support Profiles at Chain ID Company level or Merchant ID level Virtual Terminal Users If your organization will utilize Profiles on the VT in addition to the XML interface there are a few important considerations Profile User Management o Profile Administration For any VT User to administer Profiles i e add delete update that User must be provided the right to administer Profiles Any existing User can be granted this additional User permission o Profile Usage For any VT User to use Profiles for processing a transaction permission needs be granted to use profiles Any existing User can be granted this additional User permission The User will not be able to administer profiles just use existing ones o Profile Disabled If the VT User is not enabled for any Profile access level they will not see any of the functionality Profiles can be disabled for one user and enabled for another user General Access Rights December 2006 Orbital Gateway Interface Specification Page 36 o Card Masking The same card masking rules apply to Profile manag
112. of the item purchased Cannot be all zeros Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Product Code Product code ofthe item purchased Cannot be allzeros Required for Purchasing Card 3 December 2006 Orbital Gateway Interface Specification Page 77 XML Name XML Parent Element o i PC3D TaxAmt PC3Lineltem PC3D TaxRate PC3Lineltem Description Purchase Card level 3 Line Item Detail Element Number of Units Numberof units of the item purchased Cannot be allzeros Required for Purchasing Card 3 Implied decimal of 4 Purchase Card level 3 Line Item Detail Element Unit of Measurement The unit of measure orunit of measure code used forthis line item Required for Purchasing Card 3 See Table in Appendix A Purchase Card level 3 Line Item Detail Element Tax Amount The tax amount forthis item Implied decimal Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Tax Rate Taxrate applied forthis item Implied decimal of 3asa percentage Ex Interest rate of 6 2596 should be sent as 06250 Required for Purchasing Card 3 December 2006 Orbital Gateway Interface Specification Page 78 XML Name PC 3Dulinetot XML Parent Element PC 3Lineltem o o Description Purchase Card level 3 Line Item Detail Element Line Item Total For PNS customers Thisfield must equal the Unit Cost PC 3DtlUO M mu
113. on 188 2 Croatian Kuna 191 2 Cyprus Pound 196 2 Czech Koruna 203 2 Djibouti Fra nc 262 0 Dominican Peso 214 2 East Caribbean Dollar 95 2 Ecuador Sucre 218 2 Egyptian Pound 818 2 El Salvador Colon 222 2 Eritrea Nakfa 232 2 Estonian Kroon 233 2 Ethiopian Birr 230 2 Falkland Islands Pound 238 2 Fiji Dollar 242 2 Gambian Dalasi 270 2 Georgian Lari 981 2 Ghanaian Cedi 288 2 Gibraltar Pound 292 2 Guatemala Quetzal 320 2 Guinea Franc 324 2 Guinea Bissau Peso 624 2 Guyanese Dollar 328 2 Haitian Gourde 332 2 Honduras Limpera 340 2 Hungarian Forint 348 2 Iceland Krona 352 2 Indian Rupee 356 2 Indonesian Rupiah 360 2 Iranian Rial 364 2 Iraqi Dinar 368 2 Isra eli New Shekel 376 2 Jamaican Dollar 388 2 Kazakhstan Tenge 398 2 December 2006 Orbital Gateway Interface Specification Page 141 Cunency Code Exponent Kenyan Shilling 404 2 Kyrg yzsta n Som 417 2 Laos Kip 418 0 Latvian Lats 428 2 Lebanese Pound 422 2 Liberian Dollar 430 2 Lithuanian Litas 440 2 Macau Pataca 446 2 Macedonia Denar 807 2 Malagasy Franc 450 0 Malawi Kwacha 454 2 Malaysian Ringgit 458 2 Maldive Rufiyaa 462 2 Maltese Lira 470 2 Mauritania Ouguiya 478 2 Mauritius Rupee 480 2 Mexican Peso 484 2 Moldovan Leu 498 2 Mongolia Tugrik 496 2 Moroccan Dirham 504 2 Mozambique Metical 508 2 Myanmar Kyat 104 2 Namibia Dollar 516 2 Nepalese Rupee 524
114. or MasterCard only However required if an amount is sent in PC3AltTaxAmt Should not be sent for Visa Purchase Card Level 3 Altemate Tax Amount Total Amount of altemate tax associated with this transaction Implied decimal OptionalforMasterCard only However required if an amount is sent in PC 3AltTaxID Should not be sent for Visa December 2006 Orbital Gateway Interface Specification Page 76 XML Name PC 3LineltemC ount PC 3LineltemAnay PC3Lineltem PC 3DulIndex PC3Dt Desc PC 3DUProdCd XML Parent Element NewOrder PC 3LineltemAray PC 3Lineltem PC 3Lineltem PC 3Lineltem Description Purchase Card Level 3 Number of Line Items The numberof Purchasing Card 3 Line Item Detail items included with this transaction The maximum number of line itemsis 98 At least 1 line item must be included to submit Purchasing Card 3 data Required for Purchasing Card 3 Purchase Card Level 3 Detail Header Required parent tag for Purchasing Card 3 Line Item Detail components Parent XML Tag for Individual Purchase Card Level 3 Line Item Details This XML Tag isthe parent foreach Line item detail included in thistransaction It should be repeated foreach item Purchase Card Level 3 Line Item Index The sequential number 1 98 of the Line Item Details included with this tra nsaction Required for Purchasing Card 3 Purchase Card level 3 Line Item Detail Element Description Text description
115. or the Chase Paymentech Gateway is logically defined as follows The Chase Paymentech API uses XML Extensible Markup Language to make e commerce payment requests using HTTPS Hypertext Transfer Protocol Secure It allows you to submit all transaction types supported by the Orbital Gateway such as authorization authorization and capture prior authorization capture refund void and an end of day batch Communic ation Protocol The Chase Paymentech gateway supports one method of communication HTTPS This method provides a single threaded or synchronous model in which a merchant makes an HTTPS request to the gateway and then blocks until the gateway sends back HTTPS response While HTTPS is single threaded a single interface can make multiple HTTPS requests at once Posting to a URL The Orbital Gateway will only provide responses to HTTP POST requests The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request URI in the Request Line Orbital Gateway does not support GET requests The addresses for the certification and production Orbital Gateway are Orbital Gateway certification system Primary orbitalvarl paymentech net authorize on port 443 Secondary orbitalvar2 paymentech net authorize on port 443 Orbital Gateway production system Primary orbitall paymentech net authorize on port 443 Secondary
116. ot passed it will be treated as a new Activation request Salem Merchants attempting to process a Prior Activation will receive an error response Block Activate Block activation provides for the ability to activate more than one card at a time The maximum number of cards that can be activated at a time is 100 In a Block Activate request the card number of the first card in a series is defined plus the number of additional sequential cards If a Block Activation fails none of the cards in the block will be activated And the first card number that caused the Block Activation failure will be returned in the response The Virtual Terminal supports the ability to perform a Block Activation of 10 000 in a single request However as indicted above the On Line interface maximum is only 100 cards per request Deactivate This transaction is for the deactivation of a live card Passing an amount is not required for this transaction type Reactivate There are two mechanisms for reactivating a card once it has been deactivated Q Reversing the deactivation transaction which will return the card to the same balance prior to the deactivation transaction Q Orthecard can be reactivated In a reactivation transaction a dollar amount must be passed for how much the card for which will be reactivated December 2006 Orbital Gateway Interface Specification Page 24 NOTE The Orbital Gateway supports 0 activation transactions for PNS
117. ough the Virtual Terminal Interface prior to regenerating the transaction XML Request Validation on Duplic ate TRAC E Numbers The following is a description of the message validation of the XML document when the Retry Attempt is made that matches a prior Trace number Merchant ID combination The following conditions will result in an Error even if the Trace number Merchant ID Combination is a match o There is no XML Document Present o That XML Document does not pass Schema validation based on the version number passed in the MIME Header o The Merchant ID in the XML Document does not match the Merchant ID in the MIME Header o The Request Type i e Auth versus an Auth Capture versus Refund etc must be the same If the request type changes between transactions a Quick response will be returned with a ProcStatus of 9715 No other validation is associated with the XML Document of this request meaning o If that XML Document is not the same as the XML Document associated with the original request using that Trace number amp Merchant ID pair Retry Logic will still echo back the original response XML Document It does not matter if the credit card number is different or if the request type is different altogether As such it is very important when implementing Retry Logic that the Trace number process is implemented correctly Otherwise the same result could be returned for different requests multiple times Im
118. ould be the default value for this field A ACH US or Canadian Deposit the transaction by ACH only If the RDFI is notan ACH participant the transaction is rejected This is the equivalent to the BankPmtDelv element used on transactional requests Switc hSoloStartDate Profile Customer Switch Solo cards activation date Mandatory if Customer Profile Action Type Create and the Customer Payment Type Switch Solo Optional if Customer Profile Action Type Update and the Customer Payment Type Switch Solo Format MMYY This is the equivalent to the DebitCardStartDate element used on transactional requests December 2006 Orbital Gateway Interface Specification Page 109 XML Label Switc hSololssueNum XML Parent Tag Profile Req Max Description M C O Char Customer Switch Solo cards Issue Number C 2 Mandatory if Customer Profile Action Type Create and the Customer Payment Type Switch Solo Optional if Customer Profile Action Type Update and the Customer Payment Type Switch Solo Switch Solo incremental counter for lost or replacement cards This is the equivalent to the DebitCardlssueNum element used on transactional requests Field Type A N N December 2006 Orbital Gateway Interface Specification Page 110 Profile Response Elements Field Req Max Type XMLParentTag Description M C O A N gems eat pe atest ciara mms A CustomerBin profi
119. portant Note December 2006 Orbital Gateway Interface Specification Page 52 If the Trace number amp Merchant ID pair do not match a prior transaction in the previous 48 hour window the Orbital Gateway will treat that new XML Document as a new request and deal with it accordingly even if it were a duplicate transaction Transaction Types Supported The Retry Logic for initial transactions and retry attempts can be used for all transactions types Retry Error Responses When an error occurs resulting from the clients implementation of Retry Logic That XML request will not be processed Anerror will be returned in the form of a Quick Response in an XML Document just as various other Orbital Gateway errors are returned Concunency There is no limit to the number of Retry attempts on a transaction as long as they all occur within the 48 hour window However no more than two concurrent transactions with the same Trace number Merchant ID value pair can be in process with the Orbital Gateway at any given time If more than two transactions are sent while the Orbital Gateway is in the midst of processing the first two it will immediately respond in the form of a Quick Response with a ProcStatus of 9711 Too many transactions to process If this occurs it might be an indicator of a Client Problem There would never be a reason to have more than two concurrent requests in queue with the same Trace number on a particula
120. proceeds to the checkout At the checkout the cardholder may complete the purchase and payment information in a variety of ways including self entered an electronic wallet Merchant one click or using other checkout capabilities After the purchase and payment information is entered the cardholder selects the buy button The customer shopping experience is the same for both of the Issuer platforms up until the time that the Merchant Order Confirmation page is displayed The MPI activates and checks its local cache and the MC Directory Server to determine if the customer card number is part of a participating MasterCard SecureCode BIN range If so a Verify Enrollment Request message will be sent from the MPI to the MC Directory Server and forwarded to the Issuer Access Control Server ACS to determine if authentication is available for the cardholders account number The MC Directory Server sends the ACS response to the MPI If authentication is available the message response provides the web address for the Issuer ACS where the cardholder can be authenticated If authentication is not available the Merchant server receives an authentication not available message and returns the transaction to the Merchant s commerce server to proceed with a standard Authorization Request There is no attempted SecureCode transaction type unlike Verified by Visa ECI 6 The MPI sends a message and script directing the cardholder s browser to establ
121. ption profile Resp Order Desc Order Description B ultAmount profile Resp Seema ulted Transaction Amount eu d decimal d ustomerAc countType profile Resp Defines the Customers Payment Type C Credit Card S Switch Solo E Electronic Check CCAccouniNum profile Resp Customer C Customer CreditCard Number ard Number E E CExpireDate profile Resp Customer Credit Card Expiration Date ee OA ECPAccounDDA PAccountDDA profile Resp ECP DDA Account Number E NUN UE ae profileResp Defines the EC P deposit account type C Consumer Checking US or Canadian S Consumer Savings US Only X Commercial Checking US Only ECPAccountRT profileResp ECP Bank routing and transit number for the customer MW gg December 2006 Orbital Gateway Interface Specification Page 112 XML Req Max Label XMLParentTag Description d ir EC PBankPmtDiv profileResp Defines the EC P payment delivery method B Best Possible Method US Only Chase Paymentech utilizes the method that best fits the situation If the RDFI is notan ACH participant a facsimile draft will be created Thisshould be the default value for this field A ACH US or Canadian Deposit the transaction by ACH only If the RDA is notan ACH participant the transaction is rejected Switc hSoloStartDate profile Resp Customer Switch Solo cards activation date Format MMYY Switc hSololssueNum profile Re sp Customer Switch Solo cards Issue Number December
122. quest Rules and Guidelines ECP The Automated Clearing House ACH uses two fields to describe the transaction to the consumer The Merchant Name 15 bytes will always appear on the consumer s statement and the Entry Description 10 bytes will appear on the consumer s statement a majority of the time Both are required fields Chase Paymentech recommends that the Merchant Name be used for the Doing Business As DBA description and the Company Entry field be used for the product description When utilizing the Soft Descriptor for ECP transactions both the Merchant Name and the Entry Description are mandatory Soft Descriptor Examples A couple of different examples of Soft Descriptors are 3 Byte Merchant Descriptor with Phone lt SDMerchantName gt X YZ lt SDMerchantName gt lt SDProductDescription gt PA YMENT10F3 lt SDProductDescription gt lt SDMerchantCity gt lt SDMerchantPhone gt 888 888 8888 lt SDMerchantPhone gt lt SDMerchantURL gt lt SDMerchantEmail gt 12 Byte Merchant Descriptor with Email lt SDMerchantName gt XYZCOMPANY lt SDMerchantName gt lt SDProductDescription gt PYMT1OF3 lt SDProductDescription gt lt SDMerchantCity gt lt SDMerchantPhone gt lt SDMerchantURL gt lt SDMerchantEmail gt suppt xyz com lt SDMerchantEmail gt ECP December 2006 Orbital Gateway Interface Specification Page 34 Profiles lt SDMerchantName gt XYZCOMPANY12345 lt SDMerchantName gt
123. r MID As such receiving this response code could indicate that the Trace number is not always being generated uniquely when it should be or your system is not waiting for responses long enough Merchant ID Retry Logic requires that the Merchant ID be submitted in the MIME Header in addition to the XML Document The Merchant ID s submitted in the MIME Header and the XML Document must be the same or the Orbital Gateway will return an error in the form of a Quick Response with a ProcStatus of 9713 Invalid mime header Merchant ID in mime does not match XML message Retry Attempt Time Out As indicated above when a Retry Attempt is made while the Original Request is still in process the Orbital Gateway will block and wait for that original response December 2006 Orbital Gateway Interface Specification Page 53 to be created with the intent to echo that completed response in the Retry Response However the Orbital Gateway must return a result to the Client on all requests in no more than 90 seconds including a Retry Attempt Therefore there is a time limit on how long the Retry attempt will block and wait If the Original Request response is not complete prior to this window a Quick Response ProcStatus of 9710 Message expired during retry will be returned If this occurs the correct action is to make a second Retry Attempt of the transaction with the Original requests Trace number Merchant ID Pair December 2006 Orbita
124. rResp Recuning Payment Advice Code MasterCard Only M 2 N O x MEE EENE 01 New account information available Obtain new account information 02 Try again later Recycle transaction in 72 hours 03 Do not try to obtain another form of payment Raper code VR Raa StatusMsg NewOrderResp Text message associated with Proc Status value C RespMsg NewOrderResp Messages associated with RespCode C HostRespC ode NewOrderResp Actual host response code C Exact response sent by host authorization system non normalized by the gateway For those systems that have already coded to the Salem PNS authorization response values they are available via thistag December 2006 Orbital Gateway Interface Specification Page 83 XML Na me XML Parent Element o HostC VV2RespC ode NewOrderResp CustomerRefNum NewOrderResp TT ProfileProc Status NewO rderResp CustomerProfileMessage NewO rd NewOmemes BillerReferenceNumber NewO O erResp Description Actual host address verification response code Exact address verification response sent by host authorization system non normalized by the gateway For those systems that have already coded to the Salem PNS authorization response values they are available via this tag Actual host card verification response code Exact card verification response sent by host authorization system non nomalized by the gateway Forthose systems that have already co
125. ransactions have successfully passed all of the Gateway edit checks 0 Success All other values constitute an error condition See appendix for definition of those error values EndOfDa yResp Text message associated with Proc Status value bese sie pns EndOfDa yResp Time the transaction was processed by gateway Format hh24miss porem December 2006 Orbital Gateway Interface Specification Page 101 Profile Request Hements This request type is explicitly for managing Profiles and not using them including Profile Adds Updates Deletesand Inquiries XML Label XML Parent Tag Do ome NA Field Type A N Req Max M C O Char A O Description Required XML Parent Tag i Transaction Routing Definition Assigned by Chase Paymentech 000001 Salem 000002 PNS This value may not be changed through a Profile Update action This is the equivalent to the BIN gt element used on transactional requests Gateway merchant account number assigned by Chase Paymentech This account number will match that of your host platform BIN 000001 6 digit Salem Division Number BIN 000002 12 digit PNS Merchant ID This value may not be changed through a Profile Update action This is the equivalent to the Merc hantiD gt element used on transactional requests Customer Billing Name Conditionally required forelectronic check Profiles This is the equivalent to the AVSname element used on trans
126. rd Validation esee eene nemen nennnees 150 MODTO Check Di dd de tan s 150 December 2006 Orbital Gateway Interface Specification Page 5 Card Prefix Check aeuo aded ete i 153 Card Tene tly Checa 153 December 2006 Orbital Gateway Interface Specification Page 6 Version 04 2 Document Name Orbital Gateway Interface Specification V4 2 Reference Documents Request PTIA42 xsd Response PTIA42 xsd O This publication is for information purposes only and its content does not represent a contract in any form Furthermore this publication shall not be deemed to be a warranty of any kind either express or implied Chase Paymentech expressly disclaims and you expressly waive any and all warranties including without limitation those of merchantability and fitness for a particular purpose Chase Paymentech reserves the right to alter product specifications without notice No part of this publication may be reproduced or transmitted in any form or by any means electronic or mechanical including photocopy recording or any information storage or retrieval system without Chase Paymentech s permission December 2006 Orbital Gateway Interface Specification Page 7 Introduction Chase Paymentech s Orbital Gateway is a proprietary XML Internet Processing System This system works with both of Chase Paymentech s Host Processing Platforms PNS and Salem Chase Paymentech maintains two proprietary Authorization an
127. rder Shipping Destination Zip code forthe purchase C 10 A Required for Purchasing Card Level 2 and Level 3 Data ForZp Code 4 please separate with Required for best Interchange rate and cannot be all zeros ornines C 30 A PCDestName NewOrder Amex Purchasing Card Data Cardholder Ship To Name Salem Only Required for Amex Purchasing Card Data PC DestAddress1 NewOrder Amex Purchasing Card Data Cardholder Ship To Address line 1 Salem Only Required for Amex Purchasing Card Data December 2006 Orbital Gateway Interface Specification Page 74 Field XML Name XML Parent Description Req Max Type Element Char PC DestAddress2 NewOrder Amex Purchasing Card Data Cardholder Ship To Address line 2 MD DA Salem Only Required for Amex Purc hasing Card Data PCDestCity NewOrder Amex Purchasing Card Data Cardholder Ship TO City MA SI _ Stronteeueemrnertrrecon one PC DestState NewOrder Amex Purchasing Card Data Cardholder Ship TO State TE SIN Strom o PC 3FreightAmt NewOrder Purchase Card Level 3 freight amount for shipment f Total freight or shipping and handling charges Implied decimal NewOrder Purchase Card Level 3 Duty Amount for Shipment Total charges forany import and or export duties included in this transaction Implied decimal PC3DestCountryCd NewOrder Purchase Card Level 3 Destination Country Code The ISO assigned code of the country to which the goods are shipped Conditionally required for
128. retumed in all response scenarios It identifies whethertransactions have successfully passed all of the Gateway edit checks 0 Success All other values constitute an error condition See appendix December 2006 Orbital Gateway Interface Specification Page 95 Void full and partial Request Hements Field XML Name XML Parent Description Req Max Type Element M C O Char A N ELIT WA id Fort Bp vA TxRefNum Reversal Gateway transaction reference number A A unique value for each transaction which is required to adjust any transaction in the gateway such as Mark for Capture orvoid TxRefidx Reversal Gateway transaction index N Used to identify the unique components of transactions adjusted more than one time Required on for void transactions not forMark for Captures Void of Previous Txn TxRefld x Null Void of a specific Txn TxRefldx 2 Value retumed in response AdjustedAmt Reversal Transaction Amount N Keys When a specific amount isincluded with thistag that amount will be voided assuming that the amount is not greaterthan the transaction amount remaining However the absence of thistag on a void transaction will perform a full Void Implied decimal including those cumenciesthat are a zero exponent For example both 100 00 an exponent of 2 and 100 Yen an exponent of 0 should be sent as lt Amount gt 10000 lt Amount gt OrdenD Reversal Merchant Defined Order N
129. rios It identifies whethertransactions have successfully passed all of the Gateway edit checks See appendix for definition of those error values TES Wemasags sancii eed va December 2006 Orbital Gateway Interface Specification Page 122 Field XML Name XML Parent Description Req Max Type Element M C O Char A N RespTime QuickResp Time the transaction was processed by gateway M N Format hh24miss December 2006 Orbital Gateway Interface Specification Page 123 Appendix A RespCode Tag Values Response codes received that are not in this table should be treated as a general error not approved Key Action Description Call Call your Chase Paymentech Customer Service forassistance Cust Try to resolve with customer or obtain altemate payment method Fix There isan invalid value being sent Fixand resend Resend Send this transaction back at any time Voice Perform a voice authorization per instructions provided by Chase Paymentech Wait Wait 2 3 days before resending ortry to resolve with the customer Response Codes Code Definition Status Action 01 Call Referto Card Issuer Decline Voice Do Not Honor Cust 07 StopDepostOrder Deposit Order Cust Us o NENNEN authorization honor with Approved None identific ation 09 Revocation Revocation ofAuth Cust 13 Bad Amount Fix Invalid Credit Card Number Fix November 2006 Orbital Gateway Interface Specification Page 124
130. rror Bookmark not defined Retry Attempt Time Outro ais 53 Transaction Management Messages 55 New Order Request Elements ssssesesesesisesesesesesesesrsesestsrseseseresesssesssesses 55 New Order Response Elements eee 81 Mark for Capture of a previous authorization Request Elements 85 Mark for Capture Response Elements eene 94 Void full and partial Request Elements ees 96 Void full and partial Response Elements esse 98 End of Day Request Elements e ere iii 100 End of Day Response Elements siii iii 101 Profile Request Elements tidad 102 Profile Response Elements oe thee OP E es 111 FlexCache Request Elements eee eere etna 114 FlexCache Response Elements eese teen ens 118 Quick Response Blements 2e Ree eS hd ieee 122 Appendix A 124 RespCode Tas Vales mitin 124 AVSRespCode Tag Vallenar aciasa 130 CVWZRespCode Tag Valles orina as dias 132 CAVVRespCode Tag Values talentos dls 132 HTTP Responses insicuri tede petri toni io E 133 Procotatus Tag Error Values eacus ia 133 ProfileProcStatus Response Values esee 139 CurrencyCode and CurrencyExponent Tag Values 140 Purchasimg Card 3 Tables unidad di 143 ISO Country COGS ases necs moto 143 Unit of Meas ETes uan cvv edr benedic a 144 Appendix B 150 General Ca
131. s can be remapped to new Chain ID s easily If this feature will be used it is recommended that the correct chaining be validated prior to going live Whatever level is defined as the Storage level there can only be one version of a Customer Reference Number Therefore if two different Merchant ID s have different customers who share the same Customer ID it would be recommended that the Profile storage and usage be maintained at the Merchant ID level as opposed to the Chain level If the second store tried to establish the same Customer Reference Number and the setup dictated a chain level storage then a Duplicate Customer Reference Number error lt ProfileProcStatus gt error code of 9582 Salem Hierarchy For Salem Orbital Gateway customers the Orbital Gateway hierarchy closely emulates the Salem hierarchy The Orbital Gateway MID will be the same as your Salem Division or TD number And the Orbital Gateway Chain ID will be the same value as your Company Number formerly known as the MA December 2006 Orbital Gateway Interface Specification Page 39 If the Salem Division numbers are all linked to a specific Company number that is in fact how it will be setup on the Orbital Gateway PNS Hierarchy For PNS Orbital Gateway customers the Orbital Gateway hierarchy is tied to the PNS Authorization Host hierarchy As such The Orbital Gateway MID will be the same as your PNS Authorization Merchant ID MID Terminal ID
132. sing the Chase Paymentech Orbital Interface Not a recuning service Currently this feature is not a full recurring service The Orbital Gateway will store all the relevant information for processing a transaction it will not December 2006 Orbital Gateway Interface Specification Page 35 automatically process it Profile Management will still require the merchant to initiate a request to the Orbital Gateway and retrieve the result of that request Benefits There are potential benefits of using Profiles feature Itsimplifies transaction processing When making a transaction request one simply references the Profile ID a k a the Customer Reference Number and fills in any of the missing information It eliminates risk Since it eliminates the need to store sensitive information about your customer on your database merchants can focus on their business and Chase Paymentech can focus on securely processing your transactions It can eliminate data entry errors when using the Virtual Terminal By retrieving a pre existing Profile and validating the data it eliminates the risk of keying the wrong customer information such as Order which may equate to a Membership ID or credit card Setup Information For any Orbital Gateway Merchant ID to support Profiles it must be configured on the Orbital System to do so There are several different configuration aspects that must be setup Enablement First the Mercha
133. stem the Resend Count will be 0 The first time a transaction is Retried the Resend Count will be 1 If a value of greater than 1 is returned the Gateway is returning the same result many times for the same transaction It can be an indicator that a customer is un intentionally replaying the same transaction or having trouble reading the result Last Retry Attempt This MIME Header response field is returned if the Resend Count is greater than or equal to two 2 In other words it will be returned as soon as a second Retry Response is sent and all others thereafter It identifies the date and time the last time a Retry Response for the associated Trace Number and Merchant ID was returned It provided as an additional mechanism to ensure that the Retry function is behaving as expected Business Rules Retry Logic is a function available from the Orbital Gateway for client interfaces to reprocess transactions when there is an unknown result on an XML transaction request It is available to any merchant interfacing to the Orbital Gateway using XML by simply adding two new values to the MIME Header the Merchant ID and a transaction Trace number The Orbital Gateway uses this combination of values to determine the uniqueness of a transaction in determining how to process the transaction The basic process flow of Retry Logic is as follows A Request is submitted with a Trace number and Merchant ID in the MIME Header The
134. sult mod 10 sum 10 10 return mod j December 2006 Orbital Gateway Interface Specification Page 152 Card Prefix Check The prefix check is the comparison of the first few digits of each card number to a list of known prefixes Card Type Preffix American Express Optima 37 34 Bill Me Later 504990 621993 Carte Blanche 389 Diners Club 30 36 381 388 Discover Novus 60110 60112 60113 60114 60119 JCB 3528 3589 MasterCard 51 55 PINLess Debit See PINLess Debit Section Switc h Solo BIN 000001 ONLY 49 56 6 where is any single digit Visa Delta 4 Card Length Check The number of digits for each card is constant allowing a validation to be performed by verifying the number of digits for each card number Card Type Length 15 American Express Optima Bil Me Later 16 Carte Blanche 14 Diners C lub 14 Discover Novus 16 JCB 16 MasterC ard 16 PINLess Debit 12 19 Switc h Solo BIN 000001 ONLY 16 18 or19 Visa Delta 13 or 16 End of Document December 2006 Orbital Gateway Interface Specification Page 153
135. te Service This merchant is inactive Call Customer Service isretumed when required fields are missing PWS ERR VALIDATION AMOUNT PWS ERR VALIDATION AVSADDRESS PWS ERR VALIDATION AVSAPCODE F Fix Fix Fix Fix ix Orbital Gateway Interface Specification Page 134 December 2006 Code Description Action 836 PWS ERR VALIDATION ECOM 881 The LIDM you supplied does not match with any existing transaction Cannot void orMarka Transaction because the TxRefNum does match a transaction 882 LOCKED DOWN Cannot mark orunmark transaction Orbital Gateway Interface Specification Page 135 December 2006 Code Description Eon 9720 Soft Desc Merchant not activated for soft descriptors 9721 Soft Desc Merchant Name isrequired if soft descriptor Fix data is sent 9722 Soft Desc Merchant Name exceeds max length of s for s transactions 9723 Soft Desc s cannot contain leading spaces 9724 Soft Desc s exceeds max length of s 9725 Soft Desc Product Description cannot be present if Fix Merchant Name is gt s 9726 Soft Desc Product Description length cannot exc eed 945 ART if Merchant Name length is between s and s 9727 Soft Desc Too many Merchant ooi Never send Fix more than one ofthe following phone ud OR email 9728 Soft Desc 9 amp 5 is not allowed for E transactions 9729 Soft Desc Invalid format for Merchant Phone Must be nnn nnn aaaa ornnn aaaaaaaa 9737 Gateway is Down Resend 9738 D
136. tes o 14 bytes o Obytes Notes The City Field allows the merchant to identify the business location or provides the cardholder with a Customer Service Phone Number or URL This is a requirement to qualify for Visa s lowest Direct Marketing interchange rate If the merchant submits a backslash X in the merchant descriptor then it will be converted into a hyphen on the cardholder statement If the merchant submits a question mark in the merchant descriptor then it will be converted into a space on the cardholder statement December 2006 Orbital Gateway Interface Specification Page 33 There are certain American Express card types programs that ignore the descriptors send using Soft Descriptors The Optima card is one of these types The merchant should contact their American Express representative for more details Non eCommerce sent with a URL will not qualify for the best interchange For MasterCard MOTO Transaction Type 1 and Recurring Transaction Type 2 if the City Phone field at the division level is not a Customer Service Phone Number then a Customer Service Phone Number must be populated in the Merchant city Customer Phone Number field or the transaction will reject with Response Reason Code BP Customer Service Phone reqd on Tran Types 1 MO TO and 2 Recurring MC Only The Orbital Gateway will apply the asterisks in the necessary locations Please do not add these to the re
137. the actual funds Once the item has been shipped performing a Redemption Completion can complete the transaction see below Generally speaking an authorization will hold the requested funds for seven 7 days after which the funds will be available again As stated above this functionality is only available Merchants processing through the Salem Platform There are two different optional behaviors when managing Redemption Completions The next two sections outline those options Partial Redemption FlexCache supports a functionality called Partial Redemption If for whatever reason when the Redemption Completion is submitted the amount of the original authorization exceeds the available balance the merchant has two options on how to treat this transaction which is managed by submitting the XML Element lt FlexPartialRedemptionInd gt December 2006 Orbital Gateway Interface Specification Page 25 If the available balance on the card is less than the Redemption Completion Amount The transaction can be declined with no amount redeemed from the card If this is the desired behavior on a particular transaction do not submit this element or null fill it Or the transaction can be approved with the maximum amount of the Redemption completion fulfilled even though it is less The response in this circumstance would include both the Requested amount and the actual redeemed amount The behavior can be implemented by
138. the customer Should be null for electronic check processing and Profile Transactions ForBil Me Latertransactions the account number field should be populated with either the customer s Bill Me Later account number ora Bill Me Later Bank Identification Number BIN followed by ten zeros dummy account number such as 5049900000000000 The consumer s 16 byte Bill Me Lateraccount number will be retumed on all approved transactions December 2006 Orbital Gateway Interface Specification Page 56 XML Name XML Parent Description Element Field Type A N Max Char NewOrder Card Expiration Date Formats MMYY Mandatory forall card typesexcept ECP European Direct Debit Bill Me Laterand PINLess Debit except as defined below Salem BIN 000001 allowsa blank to be submitted when no known EXP date exists Please discuss this feature with your certification analyst before implementing There are three valid mechanisms for submitting a Blank expiration date using Orbital to the Salem Host They are Nullfil this XMLelement lt Exp gt Send fourspaces Exp Exp Zero fill the XML Element lt Exp gt 0000 lt Exp gt CunencyCode NewOrder Defines the transaction cunenc y The gateway using the standard ISO defines currenc y codes Keys Bin 000002 only supports the US Dollar 840 and Canadian Dollar 124 See Appendixfor complete list of supported cumencies C Big NewO BE er Defines
139. the transactions currency exponent BE Appendix for values NewOrder Supported by Visa and Discover Only 1 Value is Present 2 Value on card but illegible 9 Cardholderstates data not available NOTE If the transaction is not a Visa MasterCard or Discover transaction null fill this attribute ordo not submit the attribute at all Page 57 Mim December 2006 Orbital Gateway Interface Specification XML Name XML Parent Description Element CardSecVal NewOrder Card Verification Number Visa CVV2 3 bytes MasterCard CVC2 3 bytes American Express CID 4 bytes Discover CID 3 bytes NOTE It is against regulations to store this value DebitC ardissueNum NewOrder Switch Solo incremental counter for lost or replacement cards Tag Mandatory for Switch Solo Anincremental counterof either 1 or2 characters defined by the issuing bank If a card islost the bank issues a replacement card with the issue number being increased by one Ifthe card displays 01 submit 01 NOT 1 Ifthe card displays 1 submit 1 NOTES The DebitCardStartDate field should be submitted only when the card doesnothave an Issue Number If the card displays ONLY a Start Date and no Issue Number the DebitCardStartDate field should contain a value and the DebitC ardIssueNum field must be left blank null filled If the card displays both a Start Date and an Issue Number the DebitC ardStartDate field should be left blan
140. tion request as well as the outgoing reply MIME Header Field Definition Request MIME Header Definition The following table lists each of the required fields within the MIME Header for Orbital Gateway requests Field Definition M C POST AUTHORIZE HTTP 1 0 Fixed Header M MIME Version Should always be 1 0 or 1 1 M Content type Defines the XML version number See more M definition below Content length This value defines the length of the Request M XML Document Content transfer encoding Defines the encoding of the associated XML M document Recommended encoding is text Request number Should always be 1 M Document type Defines whether this is a Request on M Response This value should always be Request Merchant id Merchant ID See definition below C Trace number Retry Trace number See definition below C Interface Version Optional MIME Header element that can be O used by Chase Paymentech in production support See more definition below December 2006 Orbital Gateway Interface Specification Page 48 POST AUTHORIZE HTTP 1 0 This value is static and always should be presented as indicated The details of this are as described in the following sections e HTTP Post The Orbital Gateway will only provide responses to HTTP POST requests e URI The Request URI for the Orbital Gateway will always be Authorize e HTTP 1 00r1 1 Provide the HTT
141. tional for Bill Me Later Transactions Bill Me Later Cardholder Destination Billing City Should not include any of the following characters types V I Required for Bill Me Latersale transactions Bill Me Later Cardholder Destination Billing State Should not include any of the following characters types V I Required for Bill Me Latersale transactions Bill Me Later Cardholder Destination Phone Number AAAEEENNNNXXXX where AAA Area Code EEE Exchange NNNN Number XXXX Extension Optional for Bill Me Later sale transactions Field Type AVSDesiname NewOrder Bill Me Later Cardholder Destination Billing Name C 30 Required forBill Me Latersale transactions December 2006 Orbital Gateway Interface Specification Page 62 XML Name AVSDestc ountyCode CustomerProfileFromOrderind XML Parent Element NewOrder NewOrder Description Bill Me Later Cardholder Destination Address County Code Required if processing a U K based Addres Valid values US United States CA Canada GB Great Britain UK United Kingdom _ Blank forall other countries Required for Bill Me Latersale transactions Customer Profile Number generation Options A Auto Generate the CustomerRefNum S Use CustomerRefNum Element When performing an action otherthan a Customer Profile Action Type Create insert empty asit will be ignored But this Attribute is mandatory and cannot be null filled for Customer Profiles
142. transactions etc The Orbital Gateway abstracts your interface from many of these issues This section will outline what these rules are and what is necessary to understand from an Interface Perspective Authorizations Merchants are required to request authorization for all Verified by Visa and MasterCard SecureCode eCommerce transactions Merchants must supply the CAVV and ECI on all Visa authorization attempts and the AAV on all MasterCard Authorization attempts Failed Authorizations Merchants are prohibited from submitting transactions for authorization that have failed authentication Late Fulfillment When a participating merchant splits the shipment of an order each authorization component may be submitted with the authentication data ECI of December 2006 Orbital Gateway Interface Specification Page 18 5 or 6 6 is for VbV only and the CAVV or AAV of the original purchase In the event of a dispute the Acquirer must be able to establish that the authorization requests were related to a single customer authenticated purchase Furthermore if a Deposit record is sent for the subsequent shipment the authorization will already have been tagged as used therefore in order to receive the full benefit of Verified by Visa and MC SecureCode a merchant must send the authentication data with the subsequent deposit record so that when Chase Paymentech reauthorizes the authentication data can be sent as well MasterCard Secur
143. tributes Complex Type Name Profile Requests Profile Profile Response ProfileResp Mark for Capture MFC Mark a previously authorized transaction as being ready to be submitted for clearing The Mark for Capture model is present for future fulfillment models December 2006 Orbital Gateway Interface Specification Page 10 A transaction can be authorized now and marked for capture at any time in the next four months The Mark for Capture can be for any amount equal to or less than the original authorization If the amount is less than the original auth this will be treated as a split transaction The split transaction also results in the creation of a new order for the balance left over from the original authorization and adjustments as required to the original authorization Upon marking a portion or the remainder of the split transaction the system will automatically attempt to obtain a new authorization for the new order when it is settled See sample split shipment scenario SPLITSHIPMENTEXAMPLE FLOW TRANSACTION AMOUNT 20 3 20 i 20 i 20 20 1 Original Authorization Request Sent by Merchant 100 USD la There is a Marked for Capture oran Unmarked transaction for 100 2 Merchant sends Marked for Cate MC tor pan 2b System Authorization Reversal Visa Only 80 2a Original 100 Trans MFC for 20 2c New Unmarked order systemically created for remainder of original order amount 80
144. tted on the Mark for Capture MFC and the MFC is for The full amount The Purchasing Card data submitted on the MFC will override the data submitted on the Auth as long as the amended data is still consistent with the data validation rules PNS Tampa customers only otherwise the MFC capture request will fail Partial Amount Where the amount of the MFC is less than the auth and a split transaction is generated whatever data is submitted on the first mark for capture will be used on all splits If each split should have different data then each MFC should include the relevant purchasing card data But that is not required as long as the amended data is still consistent with the data validation rules PNS Tampa customers only other wise the MFC will fail If the data is not submitted on the auth then it must be included on the MFC for it to be submitted at Settlement o Where the amount submitted on the MFC is equal to the Auth the transactions is complete and that data will be used Again for PNS Tampa customers the purchasing card level 3 data must pass the data validation rules or the MFC request will fail Where the amount is less just as described above and a split transaction is generated whatever data is submitted on the first mark for capture will only be used for that transaction for Salem and PNS customers alike All subsequent MFC requests again both Salem and PNS must include the purchasing card level
145. tual authorization resulting in the debit of the customer s bank account These transactions must still be captured and settled to Chase Paymentech to support funding reporting and associated reconciliation The Orbital Gateway presently offers PINLess Debit Processing as an option for Salem BIN 000001 customers Introduction It is more commonly known as Debit Bill Payment This is a debit transaction where neither the magnetic stripe contents nor the PIN is part of the authorization message PINLess Debit is currently only supported by the three largest debit networks Star NYCE and Pulse The debit network rules for PINLess debit programs are strict and the networks that support these transactions must approve the merchant prior to their accepting PINLess debit transactions As a result PINLess debit processing is only available to merchants in selected industries specifically utilities telephone companies cable TV providers some insurance companies government entities and financial institutions This list could change so check with your account manager for availability rules December 2006 Orbital Gateway Interface Specification Page 30 The customer must initiate these transactions via the Web or IVR and the merchant assumes 100 liability for these payments Please refer to the Debit Bill Payment User Manual for card association and debit network regulations Processing Requirements As a result of the specif
146. umber M 22 A Should use the same OrdenD asthe original request XML Parent Description Req Max Element M C O Char Reversal Transaction Routing Definition M Assigned by Chase Paymentech Solutions 000001 Salem MerchantiD Reversal Gateway merchantaccount number assigned by Chase Paymentech Solutions This account number will match that of yourhost platform BIN 000001 6 digit Salem Division Number TerminallD Merchant Terminal ID assigned by Chase Paymentech Solutions All Terminal IDs at present are 001 December 2006 Orbital Gateway Interface Specification Page 97 Void full and partial Response Elements Field XML Name XML Parent Description Req Max Type Element EE LE A N Response N A Required XMLParentTag XML Parent Tag N A a poen XMLtag licis NN defines the transaction as a New Order N A pore eem Merc p Reversa IResp Gateway merchant account number assigned by Chase N Paymentech Solutions Echoesthe account number passed in the request TerminallD Reversa IResp Merchant Terminal ID assigned by Chase Paymentech M 3 N Solutions Echoesthe Terminal ID passed in the request OrdenD Reversa IResp Merchant Defined Order Number M 22 A Echoesthe Order Number passed in the request TxRefNum Reversa IResp Gateway transaction reference number M A Echoesthe Transaction Reference Number passed in the request TxRefidx ReversalResp Gateway transaction index C A Used to identify the uniqu
147. unt Redeemed on a Redemption Completion C 12 where the flexPartialRedemptionind Yes Implied Decimal Conditionally retumed Regardless of whetherthe amount redeemed isequal to orlessthan the requested amount it will be identified in thistag flexHostirace flexC acheResp Gateway transaction reference number C A unique value for each transaction which is required to adjust any transaction in the gateway such asMarkfor Capture orvoid Reversal flexAction flexC acheResp Retums the Transaction or Action Type performed from the 30 request The FlexAction retumed in the response isthe same value submitted in the request 6 flexAcctBalance flexc acheResp Cunent Balance of the HexCache Card The Balance afterthe result of the request transaction This information will retumed in all FlexCac he response messages flexAcctPriorBalance flexc acheResp Prior Balance of the HexCache Card Balance priorto the result of the request transaction This information will retumed in all FlexCache response messages A N N flexAcctExpireDate flexC acheResp The HexCache Card Expiration Date The Expiration Date of the FlexCache will be retumed if one exists This information will retumed in all response messages Response Format MMMMYY CardBrand flexC acheResp Mnemonic representing the of the request card type M 2 A FC FlexCache December 2006 Orbital Gateway Interface Specification Page 119 XML Name TxRefidx ApprovalStatus X
148. veridelnd 0A do not set this value since the Customer Reference Numberhasbeen defaulted asthe Order Description This isthe equivalent to the Comments element used on transactional requests Transaction Amount Optional if Customer Profile Action Type Create or Update Keys Implied decimal including those currenciesthat are a zero exponent For example both 100 00 an exp of 2 and 100 an exp of 0 should be sent as lt OrderDefaultA mount gt 10000 lt O rd erDefa ultA mount Given that each Orbital Gateway Merchant ID is restricted to one currency the Currency Code and Exponent is defaulted based on Merchant ID in which a transaction presented This is the equivalent to the lt Amount gt element used on transactional requests December 2006 Orbital Gateway Interface Specification Page 106 Field Req Max Type XMLParentTag Description M C O Char A N Profile Defines the Customers Payment Type C 1 A C Credit Card S Switch Solo E Electronic Check CustomerAccountlype Mandatory if Customer Profile Action Type Create Optional if Customer Profile Action Type Update This is the equivalent to the multiple XML elements used to define cardholder on transactional requests Profile Customer Credit C ard Number C 19 N CCAccountNum Mandatory if Customer Profile Action Type Create and the Customer Payment Type Credit card or Switch Solo Optional if
149. y Resend Too many transactionsto process ait amp Resend Request timeout Please try again Invalid MIMEheader Merchant ID in MIME doesnot ix match XML message Invalid MIME header Trace number must be between 1 Fix and 9999999999999999 ix The retry request did not match the original request forthis trace number Orbital Gateway Interface Specification Page 138 9716 9717 20400 20403 20408 20412 20500 20502 20503 Code Description Action IP Authentication Errors EI Security Information is Missing Call Customer Service Security Information agent c ha in merc ha nt is missing Call Customer Service A AAA Invalid Request Fix Request Timed Out Precondition Failed Security Information is missing Call Customer Service Intemal Server Error Server Unavailable Please Try Again Later ProfileProc Status Response Values Code Definition 9550 Profile Action Successful 9550 Invalid Customer Reference Number From Order indicator Fix 9551 Invalid Customer Reference Number Fix 9552 System Failure Una ble To Perform Customer Profile Call Request at This Time 9553 Invalid Action Indicator 9555 Invalid BIN 9556 Invalid Merchant ID 9572 Invalid ECP Account Route December 2006 Orbital Gateway Interface Specification Page 139 Code Definition Action 9573 Invalid ECP Bank Payment Delivery Method 9574 Invalid Switch Solo Start Date 9575 Invalid Switch Solo Issue Number 9576 Una
150. y Visa to qualify for the lowest interchange rates and protects against certain chargeback conditions As such it is highly recommended by Chase Paymentech that all transactions include this information Two keys on AVS are The minimum required data for AVS is the Cardholders billing ZIP AVS is only supported by credit cards issued in the United States Canada and the United Kingdom For PNS routed accounts BIN 000002 the Orbital Gateway does not support ZIP formats outside the US Convention of NNNNN and NNNNN NNNN If a transaction is submitted with a ZIP outside this data convention the entire transaction will reject for invalid ZIP structure For Salem routed accounts BIN 000001 the Orbital Gateway will accept ZIPs formatted alpha numeric with a length between 1 and 10 in length These ZIP s will be forwarded to the Salem authorization host The Card Types that support AVS are o Visa o MasterCard o American Express o Discover Card Verificaton Numbers The Orbital Gateway supports the submission of Card Verification Numbers see more detailed definition below for which the methods of payments it is available The specific field name for this value in the XML interface is lt CardSecVal gt Visa CVV2 MasterCard CVC 2 Discover CID Programs The Orbital Gateway supports Visa s CVV2 Card Verification Value 2 MasterCard s CVC2 Card Validation Code 2 and Discover s CID fraud reduction programs This

Download Pdf Manuals

Related Search

Related Contents

Revista da Procuradoria    Draper Traveller  Horner Electric  Adesso AKB-131UB User's Manual  Notice d`utilisation LORFLAM VS  Epson EMP-1810 User's Manual  

Copyright © All rights reserved. Failed to retrieve file