Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Payment Processing – Credit, Check, Debit

ProcessCreditCard

Endpoint URL: https://secure.ftipgw.com/ArgoFire/transact.asmx?op=ProcessCreditCard

Method: SOAP (Action: ProcessCreditCard)

Description: Submits a real-time credit card transaction for authorization and optional capture. This is the core processing endpoint for credit card payments, supporting both one-time and token-based transactions.

Request Parameters:

Name
Type
Required
Description

Username

string

Yes

API credential username

Password

string

Yes

API credential password

TransType

string

Yes

Transaction type: Sale, Auth, Return, or PostAuth

Amount

decimal

Yes

Amount to charge in dollars (e.g., 10.00)

NameOnCard

string

No

Cardholder's name

CcAccountNum

string

Conditional

Raw credit card number — required if no token is used

CcExpDate

string

Conditional

Expiration date (MMYY) — required if using raw card data

InvoiceNumber

string

No

Optional invoice number for reconciliation

Street

string

No

Optional AVS field: billing address street

Zip

string

No

Optional AVS field: billing ZIP code

ExtData

string

No

Optional XML-formatted metadata for advanced options (see Notes)

Notes:

  • Either CcAccountNum + CcExpDate or CcInfoKey must be provided — both are not required.

  • TransType values:

    • Sale – Authorizes and captures funds

    • Auth – Authorization only (for later capture via PostAuth)

    • Return – Issues a refund for a previous sale

    • PostAuth – Captures funds from a previous Auth

  • ExtData can be used to pass flags like <![CDATA[<CustRef>12345</CustRef><Force>T</Force>]]>

  • CVV is not stored and must be passed each time (if required).

  • This endpoint returns a response object that includes:

    • Result (0 = success)

    • RespMSG (e.g., "Approved")

    • AuthCode

    • TransRefID (used for lookups and reporting)

SOAP 1.1

The following is a sample SOAP 1.1 request and response. The placeholders shown need to be replaced with actual values.

SOAP 1.2

The following is a sample SOAP 1.2 request and response. The placeholders shown need to be replaced with actual values.

HTTP POST

The following is a sample HTTP POST request and response. The placeholders shown need to be replaced with actual values.

Valid Input Reference Characters

Table 1. Valid Data Characters

DEC
HEX
Character
DEC
HEX
Character
DEC
HEX
Character

32

20

(space)

63

3F

?

96

60

<code>`</code>

33

21

!

64

40

@

97

61

a

34

22

“

65

42

A

98

62

b

35

23

#

66

42

B

99

63

c

36

24

$

67

43

C

100

64

d

37

25

%

68

44

D

101

65

e

38

26

&

69

45

E

102

66

f

39

27

‘

70

46

F

103

67

g

40

28

(

71

47

G

104

68

h

41

29

)

72

48

H

105

69

i (typo note below)

42

2A

*

73

49

I

106

6A

j

43

2B

+

74

4A

J

107

6B

k

44

2C

,

75

4B

K

108

6C

l

45

2D

–

76

4C

L

109

6D

m

46

2E

.

77

4D

M

110

6E

n

47

2F

/

78

4E

N

111

6F

o

48

30

0

79

4F

O

112

70

p

49

31

1

80

50

P

113

71

q

50

32

2

81

51

Q

114

72

r

51

33

3

82

52

R

115

73

s

52

34

4

83

53

S

116

74

t

53

35

5

84

54

T

117

75

u

54

36

6

85

55

U

118

76

v

55

37

7

86

56

V

119

77

w

56

38

8

87

57

W

120

78

x

57

39

9

88

58

X

121

79

y

58

3A

:

89

59

Y

122

7A

z

59

3B

;

90

5A

Z

123

7B

{

60

3C

<

91*

—

124

7C

|

61

3D

=

94

5E

^

125

7D

}

62

3E

>

95

5F

_

126

7E

~

Table 2. XML Character Removal

These characters must be stripped by the Payment Server before submitting data to Web Service operations, to ensure correct XML parsing.

Character
XML Parser Encoding

<

&lt;

>

&gt;

&

&amp;

‘

&apos;

“

&quot;

Example: Character Removal in Action

If you submit:

  • NameOnCard = "John & James" → The & is stripped → processed as John James

  • NameOnCard = "John &amp; James" → Processed as John amp; James

RepeatSale

Description

Creates a new charge by repeating billing information used by a previous sale using its PNRef. Ideal for processing payments without re-entering full card details.

Endpoint

Required Parameters

Parameter
Required
Description

UserName

Yes

Merchant’s API username.

Password

Yes

Merchant’s API password.

TransType

Yes

Must be set to Repeat Sale.

PNRef

Yes

Reference number of the original sale to be repeated.

Sample Request

Sample Response

Response Field Notes

  • Result = 0 → indicates success

  • RespMSG → human-readable status (Approved)

  • Message → detailed response message (APPROVAL VITAL2)

  • AuthCode → authorization reference for this RepeatSale transaction

  • PNRef → new reference number assigned to the RepeatSale

  • GetCommercialCard → False indicates the card is not a commercial card

Reversal

Description

Reverses a previously authorized but unsettled credit card transaction. Unlike a Void, which cancels the transaction before settlement, a Reversal is used to cancel an authorization that has not yet been captured.

Endpoint

(Same endpoint used for all ProcessCreditCard operations.)

Required Parameters

Parameter
Required
Description

UserName

Yes

Merchant’s API username.

Password

Yes

Merchant’s API password.

TransType

Yes

Must be set to Reversal.

PNRef

Yes

Reference number of the original authorization to reverse.

Sample Request

Sample Response

Response Field Notes:

  • Result = 0 → indicates successful reversal

  • RespMSG → human-readable status (Approved)

  • Message → confirmation message (REVERSAL ACCEPTED)

  • AuthCode → authorization reference for the reversal

  • ExtData → contains batch settlement details: count, total amount, settlement timestamp

Void

Endpoint URL: https://secure.ftipgw.com/ArgoFire/transact.asmx?op=ProcessCreditCard

Description: Reverses (voids) a previously authorized yet unsettled credit card transaction.

Required Parameters:

Parameter
Required
Description

UserName

Yes

The merchant’s API username.

Password

Yes

The merchant’s API password.

TransType

Yes

Must be set to Void.

PNRef

Yes

The reference number of the original transaction to be voided.

CardNum

No

Must be passed as null (not required, but must not contain a value).

ExpDate

No

Must be passed as null (not required, but must not contain a value).

Sample Response

Response Field Notes

  • Result = 0 → indicates the void was successful

  • RespMSG → human-readable status (Approved)

  • AuthCode → approval reference code for the void

  • PNRef → new reference number created for the void transaction

ProcessCheck

Endpoint URL: https://secure.ftipgw.com/ArgoFire/transact.asmx?op=ProcessCheck

Method: SOAP (Action: ProcessCheck)

Description: Submits an electronic check (ACH) transaction using either raw bank account information or a previously generated CheckInfoKey token. Supports both Sale (debit) and Return (credit/refund) transactions.

Request Parameters:

Name
Type
Required
Description

Username

string

Yes

API credential username

Password

string

Yes

API credential password

TransType

string

Yes

Transaction type: Sale or Return

Amount

decimal

Yes

Dollar amount of the transaction (e.g., 50.00)

NameOnCheck

string

No

Optional name on the checking account

CheckNum

string

No

Optional check number (for reference only)

BankRoutingNum

string

Conditional

Required if not using CheckInfoKey

BankAccountNum

string

Conditional

Required if not using CheckInfoKey

BankAcctType

string

Conditional

"C" for Checking, "S" for Savings — required with raw account info

CheckInfoKey

string

Conditional

Tokenized bank account key — use instead of raw routing/account info

ClientTransactionID

string

No

Optional merchant-defined transaction reference

InvoiceNumber

string

No

Optional invoice number

Street

string

No

Optional billing street address (for validation/risk scoring)

Zip

string

No

Optional ZIP code (for validation/risk scoring)

Email

string

No

Optional email address for receipt

ExtData

string

No

Optional XML string for advanced configuration (see Notes)

Notes:

  • You must provide either BankRoutingNum + BankAccountNum or a valid CheckInfoKey.

  • TransType must be either:

    • Sale — Debit the account (standard ACH pull)

    • Return — Credit the account (ACH refund)

  • ExtData can carry optional XML metadata like:

  • Funds are not moved in real-time; ACH processing follows standard banking timelines (typically 1–3 business days).

  • The response includes fields such as:

    • Result (0 = success)

    • RespMSG (e.g., "Approved", "Invalid Routing Number")

    • TransRefID for future lookups

SOAP 1.1

The following is a sample SOAP 1.1 request and response. The placeholders shown need to be replaced with actual values.

SOAP 1.2

The following is a sample SOAP 1.2 request and response. The placeholders shown need to be replaced with actual values.

HTTP POST

The following is a sample HTTP POST request and response. The placeholders shown need to be replaced with actual values.

Auth Capture

Description

Performs both an authorization and a capture in one step—approving and settling a credit card transaction within the current batch (often used in terminal-based or dedicated flows).

Endpoint

Required Parameters

Parameter
Required
Description

UserName

Yes

Merchant’s API username.

Password

Yes

Merchant’s API password.

TransType

Yes

Must be set to Capture.

PNRef

Yes

Reference number of the previous authorization.

Sample Request

Sample Response

Response Field Notes:

  • Result = 0 → indicates successful authorization and capture

  • RespMSG → human-readable status (e.g., Approved)

  • Message → additional confirmation (e.g., ACCEPTED)

  • AuthCode → reference code confirming the transaction

  • ExtData → contains batch settlement details: count, total amount, settlement timestamp

ProcessDebitCard

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

Method: SOAP (Action: ProcessDebitCard)

Description: Processes real-time debit card transactions. This endpoint is used when merchants are configured for debit card routing separate from standard credit card processing. It supports Sale, Auth, Return, and PostAuth transaction types, similar to ProcessCreditCard.

Request Parameters:

Name
Type
Required
Description

Username

string

Yes

API credential username

Password

string

Yes

API credential password

TransType

string

Yes

Transaction type: Sale, Auth, Return, or PostAuth

Amount

decimal

Yes

Amount to charge in dollars (e.g., 25.00)

NameOnCard

string

No

Cardholder’s name

CcAccountNum

string

Conditional

Debit card number — required if not using CcInfoKey

CcExpDate

string

Conditional

Expiration date (MMYY) — required if using raw card data

CcInfoKey

string

Conditional

Tokenized card key — used instead of card number

Cvv2

string

Optional

3- or 4-digit security code

ClientTransactionID

string

No

Optional merchant-defined reference ID

InvoiceNumber

string

No

Optional invoice number

Street

string

No

Optional AVS field: billing street address

Zip

string

No

Optional AVS field: billing ZIP code

Email

string

No

Optional email address for confirmation or metadata

ExtData

string

No

Optional XML metadata for advanced settings (see Notes)

Notes:

  • Similar in structure to ProcessCreditCard, but uses debit routing and settlement channels.

  • Either CcAccountNum + CcExpDate or CcInfoKey must be provided.

  • TransType options:

    • Sale: Authorizes and settles the debit

    • Auth: Authorization only (for delayed capture)

    • PostAuth: Capture of a previously authorized transaction

    • Return: Refund back to the original debit card

  • Response includes:

    • Result (0 = success)

    • RespMSG (e.g., “Approved”)

    • AuthCode

    • TransRefID (used for future queries and reconciliation)

  • ExtData can include optional XML such as:

SOAP 1.1

The following is a sample SOAP 1.1 request and response. The placeholders shown need to be replaced with actual values.

SOAP 1.2

The following is a sample SOAP 1.2 request and response. The placeholders shown need to be replaced with actual values.

HTTP POST

The following is a sample HTTP POST request and response. The placeholders shown need to be replaced with actual values.

ExtData

ExtData is an XML-formatted field used to pass processor-specific, optional, or extended transaction data in a ProcessCreditCard request.

It serves as a flexible container for:

  • Processor-required fields (e.g., Wells Fargo host-based processing)

  • Transaction behavior modifiers (e.g., partial auth, duplicate handling)

  • Enhanced data (commercial cards, recurring transactions, invoice detail)

Some processors require ExtData for all transactions.

ExtData must contain well-formed XML.

Basic Structure

Nested Structure (Supported)

Structural Rules (Critical)

  • Multiple top-level elements are allowed

  • Nested elements must be properly contained

  • XML must be well-formed and valid

Invalid Example (Broken Nesting)

Issue: Mixing structured and unstructured data creates an invalid hierarchy.

Field Categories

Behavior Modifiers

Fields that change how the transaction is processed.

Field
Description
Values

Force

Allow duplicate transactions

T, F

Partial

Allow partial authorization (FSA/HSA)

T, F

TrainingMode

Enable training/test mode

T, F

Timeout

Timeout in seconds

Numeric (default: 40)

Card & Entry Data

Field
Description
Values

EntryMode

Card entry method

Manual, MagneticStripe, ICC, Proximity

CVPresence

CVV presence indicator

None, NotSubmitted, Submitted, Illegible, NotPresent

Transaction & Reference Data

Field
Description

CustomerID

Customer identifier

CustomerIDAuthCode

Original authorization code

RegisterNum

Register number

ServerID

Server identifier

PONum

Purchase order number

City

Billing city

Amount & Commercial Data

Field
Description

TipAmt

Tip amount

TaxAmt

Tax amount (commercial cards)

CustCode

Customer code (commercial cards)

Recurring Transactions

Field
Description

SequenceNum

Current transaction number

SequenceCount

Total number of transactions

Other

Field
Description
Values

BillPayment

Bill payment indicator

T, F

ExtData must contain well-formed XML.

Basic Structure

Nested Structure (Supported)

Structural Rules (Critical)

  • Multiple top-level elements are allowed

  • Nested elements must be properly contained

  • XML must be well-formed and valid

Invalid Example (Broken Nesting)

Issue: Mixing structured and unstructured data creates an invalid hierarchy.

Field Categories

Behavior Modifiers

Fields that change how the transaction is processed.

Field
Description
Values

Force

Allow duplicate transactions

T, F

Partial

Allow partial authorization (FSA/HSA)

T, F

TrainingMode

Enable training/test mode

T, F

Timeout

Timeout in seconds

Numeric (default: 40)

Card & Entry Data

Field
Description
Values

EntryMode

Card entry method

Manual, MagneticStripe, ICC, Proximity

CVPresence

CVV presence indicator

None, NotSubmitted, Submitted, Illegible, NotPresent

Transaction & Reference Data

Field
Description

CustomerID

Customer identifier

CustomerIDAuthCode

Original authorization code

RegisterNum

Register number

ServerID

Server identifier

PONum

Purchase order number

City

Billing city

Amount & Commercial Data

Field
Description

TipAmt

Tip amount

TaxAmt

Tax amount (commercial cards)

CustCode

Customer code (commercial cards)

Recurring Transactions

Field
Description

SequenceNum

Current transaction number

SequenceCount

Total number of transactions

Other

Field
Description
Values

BillPayment

Bill payment indicator

T, F

Usage Guidelines

Use ExtData when:

  • Required by the processor

  • Implementing advanced features (recurring, Level 2/3, invoice data)

  • Passing fields not available in the standard request

Behavior Notes

  • ExtData is not strictly validated at the platform level

  • Validation and requirements are often processor-specific

  • Unsupported fields may be ignored or cause failure

Partial Authorization

If Partial = T, the processor may approve less than the requested amount. Integrations must handle partial approvals accordingly.

Use ExtData when:

  • Required by the processor

  • Implementing advanced features (recurring, Level 2/3, invoice data)

  • Passing fields not available in the standard request

PreviousTransaction Lifecycle & Status CodesNextTokenization Services

Last updated