ArgoFire Gateway
| ProcessDebitCard | ![]() |
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 | Value |
|---|---|
| UserName | Required. User name assigned in the payment server |
| Password | Required. Password for the user name assigned in the payment server |
| TransType |
|
| 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:
|
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:
- ) Open Query Analyzer
- ) Set the current database to your server database
- ) Paste the above script into the query editor and change ‘Your Application Name' to your company name
- ) 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
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.
Examples
ArgoFire Gateway SDK - Main |
Glossary of Terms |
Response Codes |
|
![]() |
|||

