This Web service operation processes debit card transactions for a merchant. The URL to access this Web service is:

https://secure.ftipgw.com/ArgoFire/transact.asmx?op=ProcessDebitCard

Descriptions of the parameters are listed below.

Parameter Description
UserName Required. User name assigned in the payment server
Password Required. Password for the user name assigned in the payment server
TransType
  • Sale to make a purchase on a debit card
  • Return to credit the cardholder’s account
  • Auth to authorize an amount on a debit card. Pertains only to Concord EFS fuel transactions
  • Force to place Auth transactions into the current batch (PostAuth). Pertains only to Concord EFS fuel transactions
  • Capture to settle a single transaction in the current batch; only for terminal-based processors
  • CaptureAll to settle all transactions in the current batch; only for terminal-based processors or host-based processors that support a batch release feature
CardNum Required except for Capture and CaptureAll. Debit card number to process the transaction
ExpDate Required except for Capture and CaptureAll. Debit card’s expiration date in MMYY format
MagData Required except for Capture and CaptureAll; required for all swiped card transactions. Data located on the track 2 of the magnetic strip of the card. Once this field is populated, the transaction will be indicated as Card-Present transaction and usually result in a more favorable retail discount rate. This parameter will remove invalid characters. See List of Removed Characters for more details.The format of the MagData (or Track 2 data) is CardNum=ExpDate followed by the service code and checksum. For example, 36438999960016=05121015432112345678
NameOnCard Optional, depending on different merchant processor setup. The cardholder’s name as it appears on the card. This parameter will remove invalid characters. See List of Removed Characters for more details
Amount Required except for CaptureAll. The total transaction amount in DDDD.CC format. This amount includes CashBackAmt and SureChargeAmt
InvNum Optional. Invoice tracking number. This parameter will remove invalid characters. See List of Removed Characters for more details
PNRef Optional except for Force and Capture. The reference number assigned by the payment server
Pin Required except for Capture and CaptureAll transactions and PIN-less debit transactions. The encrypted pin block returned by the pin-pad. The transaction will fail if an unencrypted pin value is used
RegisterNum Optional. A number uniquely identifies the register or computer on which the transaction is performed. This parameter will remove invalid characters. See List of Removed Characters for more details
SureChargeAmt Optional. The amount in DDDD.CC format that a merchant charges for processing a debit card transaction
CashBackAmt Optional. The amount in DDDD.CC format that a cardholder requests for cash back
ExtData

Optional, except for <KeySerialNumber>, which is required for all non-PINless Sale, Auth, Force, and Return debit transactions, and <Items> and associated nested data elements (required for Concord EFS fuel purchases- see section below). Extended data in XML format. Valid values are:

  • <TimeOut>TimeOut</TimeOut > for timeout value in seconds (default = 40)
  • <TrainingMode>TrainingMode</TrainingMode> to process transaction in Training Mode; either T or F
  • <KeySerialNumber>KeySerialNumber</ KeySerialNumber > for managing DUKPT pin-pads for non-PIN-less debit transactions
  • <Force>Force</Force> for forcing duplicate transactions to be processed; either T or F. Note that some processors, including Concord EFS, will not utilize this tag and may still reject a duplicate transaction
  • <Items> Required for Concord EFS fuel purchases. Items included in invoice. Contains one or more <Item> elements
    • <Item> Required for Concord EFS fuel transactions of type Sale and Force. One item in invoice (item details nested within). There may be multiple <Item> nested within <Items> tag
        • <SKU>SKU</SKU> SKU number of item
        • <UPC>UPC</UPC> Required for Concord EFS fuel purchases. The NACS (National Association of Convenience Stores) product code for fuel purchases. The NACS is an industry standard list that Concord is utilizing. For a list of NACS product codes, please contact EFSnet™ customer support at support@concordefsnet.com or 1-877-852-2637.
        • <Description>Description</Description> Item description
        • <Quantity>Quantity</Quantity Required for Concord EFS fuel purchases. Quantity purchased of item
        • <UnitOfMeasurement>UnitOfMeasure</UnitOfMeasurement > Unit of measurement for item
        • <UnitPrice>UnitPrice</UnitPrice> Required for Concord EFS fuel purchases. Unit price of item
        • <DiscountAmt>DiscountAmount</DiscountAmt> Possible discount amount on item
        • <TaxAmt>TaxAmt</TaxAmt> Possible tax amount on item
        • <TotalAmt>TotalAmt</TotalAmt> Total amount of item
        • <Category>Category</Category> Required for Concord EFS

      fuel purchases. The specific value Fuel to designate fuel purchases

      • <TaxRate>TaxRate</TaxRate> Possible tax rate applied to item
    • </Item>
  • </Items>

PIN-Less Debit Transactions
In some cases, debit transactions can actually be processed without the customer’s entering a PIN number (a “PIN-less” debit transaction). Essentially, the same information is sent as in a typical PIN-based debit transaction, with the exception of the encrypted PIN-block and key serial number. This transaction type is currently only available with Concord EFS and Global Payments processors.

So, if the processor is not Concord or Global, then both the PIN-block and key serial number are required, and without both pieces of data, a transaction will be rejected at the Payment Server. If the designated processor is Concord or Global, then the transaction will be accepted either with both pieces of data (interpreted as a PIN-based debit transaction) or accepted with neither piece of data (interpreted as a PIN-less debit transaction). See Example 3 below.

After the above requirements are met for a transaction, a PIN-less debit transaction will be allowed through the Payment Server. However, it still must have sufficient information to be accepted as a PIN-less transaction only when Concord is the processor. In order for the proper information to be forwarded to Concord for PIN-less debit (and thus for the transaction to be accepted at the processor), the Payment Server must be configured as described below:

Application ID Setup
To process PIN-less debit through Concord, the Application Id sent to Concord must be specified to identify the application in use. Use the following SQL script to change this value in your database:

INSERT INTO [dbo].[AppSetting_T] ([Application_Key], [AppSetting_Key], [AppSetting_Value], [XmlProfile_TXT]) VALUES (8, ‘CustomAppName’, ‘Your Application Name’, ”)

In the above script, you must change ‘Your Application Name’ to the Application ID value Concord is expecting, which is typically your company name. Follow these steps in order to execute this script:

  1. Open Query Analyzer
  2. Set the current database to your server database
  3. Paste the above script into the query editor and change ‘Your Application Name’ to your company name
  4. Execute the script and verify its success

The CustomAppName is only sent to Concord for PIN-less debit transactions. If CustomAppName is not specified, then the default Application ID will be sent.

Register Number and Terminal Id Setup
When processing transactions with Concord, the Payment Server will detect that the register number passed from the client-side application matches the Register Number field setup in the merchant account. Once it has made the match, then it will send the corresponding Terminal ID field set up for that Register Number to Concord. When no Terminal ID field is sent to Concord, it defaults to what is set up at the processor (usually Terminal ID “01”). If you are also doing VRU (phone-originated) transactions, a separate Terminal ID field will need to be set up in the Registers of the merchant account and submitted in your request through the Web Service. However, if the merchant will be doing both Internet and VRU transactions at the same time, the Terminal ID value will be required to differentiate between the two. For example, you may set up “01” for Internet and “02” for VRU, and the request sent through the ProcessDebitCard operation, from the merchant’s PIN-less Debit application, must send the appropriate Register Number to reflect what Terminal ID should be sent.

Fuel Purchases: Debit Card Use
Debit card processing for fuel purchases is now available, currently through Concord EFS only. This functionality allows for fuel purchases with standard debit cards (Visa, Mastercard, etc). Debit fuel purchases (TransType’s Sale and Force) require item-level purchase information. If all the required information for a certain purchase is not provided, the transaction will be rejected and an error message generated. The main implication for the developer is that additional data must be passed to the gateway in order for fuel purchases to process correctly.

Item-level debit fuel purchase information is passed inside the tag in ExtData. Fuel purchases are differentiated at the gateway from other purchases by the Fuel designation placed within the tag in item descriptions (see Examples 4 through 6 below). In effect, a transaction will only be treated as a fuel transaction if at least one of the items within is designated as category Fuel. See the above chart for details on these and other required XML tags for standard debit card processing on fuel transactions.

Note that PIN information and Key Serial Data must be passed on all debit transactions. This data will not be retained after a transaction, so the customer must be present to reenter the PIN. This is important in the case of a Force (PostAuth). See examples 5 and 6 below.

Example: Swiped Sale
The example data below will process a swiped debit card Sale transaction through the payment server.

Parameter Value
UserName test
UserName 123
TransType Sale
CardNum 4055011111111111
ExpDate ExpDate
MagData 4055011111111111=05121015432112345678
NameOnCard John Doe
Amount 1.00
InvNum 1001
Pin 6366C0466A74C3F6
CashBackAmt 0.5
ExtData <Timeout>100</Timeout><KeySerialNumber>4A003102930003BB</KeySeri alNumber>


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>

<Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><RespMSG>Approved</RespMSG><Message>APPROVAL VITAL7</Message><AuthCode>VITAL7</AuthCode><PNRef>2428</PNRef><Ext Data>InvNum=1001,CardType=DEBIT</ExtData>

</Response>

Example: Swiped Return
The example data below will process a swiped debit card Sale transaction through the payment server.

Parameter Value
UserName test
Password 123
TransType Return
CardNum 4055011111111111
ExpDate 1205
MagData 4055011111111111=05121015432112345678
NameOnCard John Doe
Amount 1.00
PNRefm 2428
Pin 6366C0466A74C3F6
ExtData <KeySerialNumber>4A003102930003BB</KeySerialNumber>


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>

<Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><RespMSG>Approved</RespMSG><Message>APPROVAL VITAL9</Message><AuthCode>VITAL9</AuthCode><PNRef>2430</PNRef><Ext Data>CardType=DEBIT</ExtData>

</Response>

Example: PIN-Less Swiped Sale
The example data below will process a swiped PIN-less debit card Sale transaction through the payment server. Note that this will currently only work with specific payment processors and will be processed as PIN-less debit when both the PINblock and key serial number information are purposefully omitted.

Parameter Value
UserName test
Password 123
TransType Sale
CardNum 4011190070070071
ExpDate 0606
MagData 4011190070070071=060600199100
NameOnCard John Doe
Amount 1.00


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>
<Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><Message>APPROVAL</Message><AuthCode>216880</AuthCod e><PNRef>38472</PNRef><HostCode>100008691797</HostCode><ExtData>C ardType=DEBIT</ExtData>

</Response>

Example: Fuel Sale
The example data below will process a swiped debit card Sale transaction as a fuel transaction through the payment server.

Parameter Value
UserName test
Password 123
TransType Sale
CardNum 4011190070070071
ExpDate 0606
MagData 4011190070070071=060600199100
NameOnCard John Doe
Amount 1.00
Pin A0C98099B1341075
ExtData <KeySerialNumber>1234567890000343</KeySerialNumber><Items><Item ><UPC>001</UPC><Quantity>1</Quantity><UnitPrice>1</UnitPrice><Cat egory>Fuel</Category><Description>UnLeaded</Description><UnitOfMeasu rement>Gallon</UnitOfMeasurement></Item></Items>


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>

– <Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><Message>APPROVAL</Message><AuthCode>245028</AuthCo de><PNRef>39548</PNRef><HostCode>100008813318</HostCode><ExtData> CardType=DEBIT</ExtData>

</Response>

Example: Swiped Auth
The example data below will process a swiped debit card Auth transaction through the payment server.

Parameter Value
UserName test
Password 123
TransType Sale
CardNum 4011190070070071
ExpDate 0606
MagData 4011190070070071=060600199100
NameOnCard John Doe
Amount 50.00
Pin A0C98099B1341075
ExtData <KeySerialNumber>1234567890000343</KeySerialNumber>


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>

– <Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><Message>APPROVAL</Message><AuthCode>245267</AuthCo de><PNRef>39549</PNRef><HostCode>100008813334</HostCode><ExtData> CardType=DEBIT</ExtData>

</Response>

Example: Force Auth
The example data below will process a swiped debit card Force transaction (after Example 5 Auth) as a fuel transaction through the payment server. The PNRef parameter should be changed when testing this example yourself.

Parameter Value
UserName test
Password 123
TransType Force
CardNum 4011190070070071
ExpDate 0606
MagData 4011190070070071=060600199100
NameOnCard John Doe
Amount 50.00
PNRef 39549
Pin A0C98099B1341075
ExtData <KeySerialNumber>1234567890000343</KeySerialNumber><Items><Item><UPC >001</UPC><Quantity>1</Quantity><UnitPrice>1</UnitPrice><Category>Fuel</ Category><Description>UnLeaded</Description><UnitOfMeasurement>Gallon</Un itOfMeasurement></Item></Items>


Response
<?xml version=”1.0″ encoding=”utf-8″ ?>

– <Response xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”https://secure.ftipgw.com/ArgoFire/”>

<Result>0</Result><Message>APPROVAL</Message><AuthCode>245267</Aut hCode><PNRef>39554</PNRef><HostCode>100008813347</HostCode><ExtDat a>CardType=DEBIT</ExtData>

</Response>