WIXLIB

Orbital GatewayInterface SpecificationV 4.302-22-08

Change LogFebruary 2008DateActionDescription of Change09/01/06Rewrite11/01/06UpdatedAdded Bill Me Later in Schema version 4.112/01/06UpdatedAdded PINLess Debit02/01/08UpdatedUpdated for Schema 4.3.Added Managed Billing, Auth Recycling02/01/08UpdatedAdded Return via TxRefNum02/01/08UpdatedClarified Address Verification wording, added AVS format table02/01/08UpdatedAdded note to Purchasing Card section about Salem P-cardedits and rejected batches02/01/08UpdatedAdded AVS Country Code, EU DD, Soft Descriptor support toProfile sections.02/01/08UpdatedChanged “FlexCache” to “Gift Card” wherever possibleOrbital Gateway Version 4.0 is a brand new schema thatrequires the specification to be rewrittenOrbital Gateway Interface SpecificationPage 2

Table of ContentsIntroduction8Chase Paymentech Orbital Gateway Transaction Processing Model .8Transaction Types .9New Order .9Gift Card (formerly FlexCache) Transactions .10Profile Transaction Types .10Mark for Capture [MFC].11Reversal [Void a Previous Transaction].11End of Day .12Quick response .12Cardholder Authentication (Card Not Present) .13Address Verification.13Card Verification Numbers .14Verified by Visa/MasterCard SecureCode Programs .15Purchasing Card.20Introduction .20Edit Checks .21BIN Ranges.21Processing.21European Direct Debit.23Introduction .23Gift Card (formerly FlexCache) .24Transaction Types .24Responses .28Settlement.29Reporting.29Bill Me Later.29Introduction .29How it works .29Processing Requirements.30February 2008Orbital Gateway Interface SpecificationPage 3

Other .31PINLess Debit .31Introduction .31Processing Requirements.32Supported Currencies.33Virtual Terminal.33Soft Descriptors .33Introduction .33Soft Descriptor Support.33Salem Support .34PNS/Tampa Support .36Profiles and Managed Billing .36Supports both Recurring and non-Recurring charges.36Benefits .37Setup Information .37Business Rules .38Processing Interface Description49Introduction .49Communication Protocol .49Posting to a URL .49Security .50Secure Sockets Layer Implementation Required.50Authentication.51XML Schema .51MIME Header .52MIME Header Field Definition .52Retry Logic .55Business Rules .55Retry Timing .56XML Request Validation on Duplicate TRACE-Numbers.56Transaction Types Supported .57Retry Error Responses .57Concurrency.57Merchant ID .57February 2008Orbital Gateway Interface SpecificationPage 4

Retry Attempt Time Out .57Transaction Management Messages59New Order Request Elements.59New Order Response Elements .88Mark for Capture (of a previous authorization) Request Elements .92Mark for Capture Response Elements .101Void (full and partial) Request Elements .103Void (full and partial) Response Elements.105End of Day Request Elements .107End of Day Response Elements .108Profile Request Elements .109Profile Response Elements.125Gift Card (FlexCache) Request Elements .130Gift Card (FlexCache) Response Elements.134Quick Response Elements.138Appendix A140RespCode Tag Values.140AVSRespCode Tag Values.146Cardholder Verification Data Response Codes (CVV2RespCode TagValues) .148CAVVRespCode Tag Values .148HTTP Responses .149ProcStatus Tag Error Values.149ProfileProcStatus Response Values .156CurrencyCode and CurrencyExponent Tag Values .157Purchasing Card 3 Tables .160ISO Country Codes .160Unit of Measure.161Appendix B167General Card Validation .167MOD 10 Check Digit .167February 2008Orbital Gateway Interface SpecificationPage 5

Card Prefix Check .170Card Length Check .170February 2008Orbital Gateway Interface SpecificationPage 6

Version: 04.3Document Name: Orbital Gateway Interface Specification V4.3Reference Documents : Request PTI43.xsdResponse PTI43.xsd This publication is for information purposes only and its content does notrepresent a contract in any form. Furthermore, this publication shall not bedeemed to be a warranty of any kind, either express or implied. ChasePaymentech expressly disclaims, and you expressly waive, any and allwarranties, including without limitation those of merchantability and fitness fora particular purpose. Chase Paymentech reserves the right to alter productspecifications without notice. No part of this publication may be reproduced ortransmitted in any form or by any means, electronic or mechanical, includingphotocopy, recording, or any information storage or retrieval system, withoutChase Paymentech's permission.February 2008Orbital Gateway Interface SpecificationPage 7

IntroductionChase Paymentech’s Orbital Gateway is a proprietary XML Internet ProcessingSystem. This system works with both of Chase Paymentech’s Host ProcessingPlatforms - PNS and Salem.Chase Paymentech maintains two proprietary Authorization and Depositplatforms. The PNS platform, which is sometimes referred to as the Tandem orTampa, is primarily targeted to Retail and smaller customers. The Salemplatform, sometimes referred to as the Stratus, is primarily targeted to Card-NotPresent and larger customers. Despite name, both systems are collocated in bothTampa, 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 informationas presented in this specification, with the exception of any features that mayonly be available on one of the two Platforms. Throughout this document therewill be references to BIN 000001 (Salem Platform) or BIN 000002 (PNS Platform).Please contact your technical analyst or relationship manager if you are unsurewhich Platform your merchant account resides on.Chase Paymentech Orbital GatewayTransaction Processing ModelThe Chase Paymentech Orbital Gateway described in this document operates onthe basis that a merchant initially instructs the gateway to perform an operationon his/her behalf. Assuming that the initial operation is successful, the gatewayreturns information that the merchant must use for all subsequent operations onthe transaction in question.The gateway manages the “transaction state” on behalf of the merchant. Themerchant moves the transaction between the various possible states using theAPI messages and fields defined in this document.February 2008Orbital Gateway Interface SpecificationPage 8

Transaction TypesThe Chase Paymentech Orbital Gateway XML interface offers the followingtransaction types:New OrderAuthorization: Authorize the supplied information. This transaction type shouldbe used for deferred billing transactions.Authorization-Capture: Authorize the supplied information and mark it ascaptured for next settlement cut. This transaction should be used for immediatefulfillment.Force Authorization-Capture: Force transactions will not generate newauthorizations. A ‘good’ response simply indicates that the request has beenproperly formatted. And the Orbital Gateway will settle the captured force atthe next settlement event.Refund: Instruct the gateway to generate a refund [credit] based on the suppliedinformation. Refund via TxRef Num - a Refund can be generated for a previous chargeusing the TxRefNum of the original transaction. If no amount is sent, theoriginal transaction amount will be refunded. If an amount is sent, thatamount must be equal to or less than the original amount. See thedetailed New Order formats later on in this document for more details.Complex Type Name:-New Order Request NewOrderNew Order Response NewOrderRespProfile Transactions in New Order [see more details in Profiles section]:The following are the Profile actions that can be executed in a New OrderTransactionUsing Profiles for a 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 included a fixed amount, but a particular transaction was for adifferent amount, it could be changed for that transaction by including aspecific amount in the use profile request.Adding Profiles during an AuthGiven that in many circumstances, the fist time a customer is setup anauthorization needs to be performed, the Orbital Gateway has extended theFebruary 2008Orbital Gateway Interface SpecificationPage 9

traditional Authorization transaction to enable adding a Profile in the samerequest.-Add profiles can be included with all New Order transactions types exceptRefunds.Gift Card (formerly FlexCache) TransactionsAs opposed to using the New Order transaction type for creating new Gift CardTransactions, the ‘Gift Card’ Element is used.This supports the following Gift Card transactional capabilities:--Card Activation:o Single Card Activationo Block Activationo Deactivateo ReactivateAdd fundBalance InquiryVoid [Reversal]Gift Card Reversals are generated by sending a Reversal [Void] on the originalrequest. Please see reversal section below.Complex Type Name:-FlexCache Request FlexCacheFlexCache Response FlexCacheRespProfile Transaction TypesThis transaction type allows for the following profile actions [see Profiles sectionfor details]:-Add a ProfileDelete a ProfileUpdate a ProfileRetrieve a profile [and all its attributes]Complex Type Name:-February 2008Profile Requests ProfileProfile Response ProfileRespOrbital Gateway Interface SpecificationPage 10

Mark for Capture [MFC]Mark a previously authorized transaction as being ready to be submitted forclearing. The Mark for Capture model is present for future fulfillment models.A transaction can be authorized now and marked for capture at any time in thenext four months. The Mark for Capture can be for any amount equal to or lessthan the original authorization. If the amount is less than the original auth, thiswill be treated as a split transaction.The split transaction also results in the creation of a new order for the balance leftover from the original authorization and adjustments as required to the originalauthorization. Upon marking a portion or the remainder of the split transaction,the system will automatically attempt to obtain a new authorization for the neworder when it is settled.See sample split shipment scenario.SPLIT SHIPMENT EXAMPLE FLOW:TRANSACTION AMOUNT 20 20 20 20 201. Original Authorization Request Sent by Merchant 100 USD1a.There is a Marked for Capture or an Unmarked transaction for 1002. Merchant sends Marked forCapture (MFC) for 202b. System Authorization Reversal (Visa Only): 802a. Original 100 Trans. MFC for 202c. New "Unmarked" order systemically created for remainder of original order amount: 803. Merchant sends MFC for 303c. New "Unmarked" order systemically created for remainder of split: 503a. System performs Auth request for 303b. Unmarked 80 transaction now MFC for 504. Merch. sendsMFC for 104c. New "Unmarked" order systemically created for remainder of split: 404a. Syst. PerformsAuth for 104b. Unmkd 50now MFC for 105. Merchant sends MFC for 405a. System performs new Auth request for 405b. Unmarked 40 now MFC for 40TRANSACTION KEY:- Authorization Request- Marked Transaction- Mark for Capture [MFC] Request- Unmarked TransactionComplex Type Name:-Mark for Capture Request MarkForCaptureMark for Capture Response MarkForCaptureRespReversal [Void a Previous Transaction]This transaction is for voiding a previous transaction [except Gift Cardtransactions] either in the full amount or partial. If a Reversal (void) request issent for a partial amount, the transaction will be split into two components. Avoided transaction in the amount of the partial void request and the remainder ofFebruary 2008Orbital Gateway Interface SpecificationPage 11