Network Merchants (NMI)

Integration Resources
Direct Post API
Documentation
June 2007
Table of Contents
Methodology........................................................................................................ 2 
Direct Post Method (Server to Server) FIG. 1 ................................................................ 2 
Transaction Types .............................................................................................. 3 
Sale (sale) ........................................................................................................................ 3 
Authorization (auth) ........................................................................................................ 3 
Capture (capture) ............................................................................................................ 3 
Void (void) ...................................................................................................................... 3 
Refund (refund) ............................................................................................................... 3 
Credit (credit) .................................................................................................................. 3 
Update (update) ............................................................................................................... 3 
Transaction Variables ......................................................................................... 4 
Sale/Authorization/Credit ............................................................................................... 4 
Capture ............................................................................................................................ 5 
Void................................................................................................................................. 5 
Refund ............................................................................................................................. 5 
Update ............................................................................................................................. 5 
Transaction Response Variables....................................................................... 6 
Standard Response .......................................................................................................... 6 
Retail Data ........................................................................................................... 6 
Passing Retail Magnetic Stripe Data............................................................................... 6 
Testing Information ............................................................................................ 7 
Transaction Testing Account .......................................................................................... 7 
Transaction POST URL .................................................................................................. 7 
Test Transaction Information .......................................................................................... 7 
Triggering Errors in Test Mode ...................................................................................... 8 
Examples ............................................................................................................. 8 
Direct Post Format .......................................................................................................... 8 
Changelog ........................................................................................................... 8 
Appendix 1 – AVS Response Codes ................................................................. 9 
Appendix 2 – CVV Response Codes ................................................................. 9 
Appendix 3 – response_code Lookup Table .................................................. 10 

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 1

Methodology
There are two primary options in which transactions can be submitted through the
Payment Gateway API. The simplest, most direct, and transparent method is our
Direct Post Method. This document describes the Direct Post Method.

Direct Post Method (Server to Server) FIG. 1

1. The customer sends their payment
information to the merchant’s web site.
2. The merchant’s web site posts the payment
data to the Payment Gateway.
3. The Payment Gateway responds
immediately with the results of the
transactions.
4. The merchant’s web site displays the
appropriate message to the customer.

The communication method used to send messages to the Payment Gateway’s

server is the standard HTTP protocol over an SSL connection.

In the Direct Post method, the communications with the cardholder (Steps 1 and
4) are developed completely by the merchant and therefore are not defined by the
Payment Gateway. Step 1 should simply collect the payment data from the
cardholder and Step 4 should display the appropriate transaction receipt or
declined message.

In Step 2, transaction details should be delivered to the Payment Gateway using

the POST method with the appropriate variables defined below posted along with
the request.

In Step 3, the transaction responses are returned in the body of the HTTP
response in a query string name/value format delimited by ampersands. For
example: variable1=value1&variable2=value2&variable3=value3

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 2

Transaction Types
Sale (sale)

Transaction sales are submitted and immediately flagged for settlement.

These transactions will automatically be settled.

Authorization (auth)

Transaction authorizations are authorized immediately but are not flagged

for settlement. These transactions must be flagged for settlement using
the capture transaction type. Authorizations typically remain activate for
three to seven business days.

Capture (capture)

Transaction captures flag existing authorizations for settlement. Only

authorizations can be captured. Captures can be submitted for an amount
equal to or less than the original authorization.

Void (void)

Transaction voids will cancel an existing sale or captured authorization.

In addition, non-captured authorizations can be voided to prevent any
future capture. Voids can only occur if the transaction has not been
settled.

Refund (refund)

Transaction refunds will reverse a previously settled transaction. If the

transaction has not been settled, it must be voided instead of refunded.

Credit (credit)

Transaction credits apply a negative amount to the cardholder’s card. In

most situations credits are disabled as transaction refunds should be used
instead.

Update (update)

Transaction updates can be used to update previous transactions with

specific order information, such as a tracking number and shipping carrier.

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 3

Transaction Variables
Sale/Authorization/Credit

Variable Name Required* Format Description

type Required sale / auth / credit sale = Transaction Sale
auth = Transaction Auth
credit = Transaction Credit
username Required Username assigned to merchant account
password Required Password for the specified username
ccnumber Required** Credit card number
ccexp Required** MMYY Credit card expiration (ie. 0711 = 7/2011)
checkname Required** The name on the customer’s ACH Account.
checkaba Required** The customer’s bank routing number
checkaccount Required** The customer’s bank account number
account_holder_type Required** business / personal The customer’s type of ACH account
account_type Required** checking / savings The customer’s ACH account entity
sec_code Optional** PPD/WEB/TEL/CCD ACH Standard Entry Class codes
amount Required x.xx Total amount to be charged (i.e. 10.00)
cvv Recommended Card security code
payment Optional ** creditcard / check Set Payment Type to ACH or Credit Card
processor_id Optional If using Multiple MIDs, route to this
processor. processor_id is obtained under
Options->Load Balancing in the Control Panel
dup_seconds Optional Disable Duplicate checking (in seconds)
(On supported processors)
descriptor Optional Set payment descriptor
(On supported processors)
descriptor_phone Optional Set payment descriptor phone
(On supported processors)
product_sku_# Optional product_sku_1 Associate API call with Recurring SKU
orderdescription Optional Order description
orderid Optional Order Id
ipaddress Recommended xxx.xxx.xxx.xxx IP address of the cardholder
tax Level II x.xx Total tax amount
shipping Level II x.xx Total shipping amount
ponumber Level II Original Purchase Order
firstname Recommended Cardholder’s first name
lastname Recommended Cardholder’s last name
company Optional Cardholder’s company
address1 Recommended Card billing address
address2 Optional Card billing address – line 2
city Recommended Card billing city
state Recommended CC Card billing state (2 character abbrev.)
zip Recommended Card billing zip code
country Recommended CC (ISO-3166) Card billing country (ie. US)
phone Recommended Billing phone number
fax Optional Billing fax number
email Recommended Billing email address
validation Optional Specify which Validation processors to use. If
variable is passed blank, use none.
shipping_firstname Optional Shipping first name
shipping_lastname Optional Shipping last name

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 4

shipping_company Optional Shipping company
shipping_address1 Optional Shipping address
shipping_address2 Optional Shipping address – line 2
shipping_city Optional Shipping city
shipping_state Optional Shipping state
shipping_zip Optional Shipping zip code
shipping_country Optional CC (ISO-3166) Shipping country (ie. US)
shipping_email Optional Shipping email address
*These fields are required by default. Level II fields are required for Level II processing. Recommended fields help
provide additional address and cardholder verification. Please Note, Certain banks may require some optional fields.
**You can pass only Credit Card or E-Check transaction variables in a request – not both in the same request.

Capture

Variable Name Required Format Description

type Required capture capture = Transaction Capture
username Required Username assigned to merchant account
password Required Password for the specified username
transactionid Required Original Payment Gateway transaction id
amount Required x.xx Total amount to be settled (i.e. 10.00)
This amount must be equal to or less than the
original authorized amount.
tracking_number Optional Shipping Tracking Number
shipping_carrier Optional ups/fedex/dhl/usps Shipping Carrier
orderid Optional Order Id

Void

Variable Name Required Format Description

type Required void void = Cancel unsettled Transaction
username Required Username assigned to merchant account
password Required Password for the specified username
transactionid Required Original Payment Gateway transaction id

Refund

Variable Name Required Format Description

type Required refund refund = Refund Transaction
username Required Username assigned to merchant account
password Required Password for the specified username
transactionid Required Original Payment Gateway transaction id
amount Optional x.xx Total amount to be refunded (i.e. 10.00)
This amount may be equal to or less than the
settled amount.

Update

Variable Name Required Format Description

type Required update update = Update an un-captured Transaction
username Required Username assigned to merchant account
password Required Password for the specified username
transactionid Required Original Payment Gateway transaction id

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 5

tracking_number Optional Shipping Tracking Number
shipping_carrier Optional ups/fedex/dhl/usps Shipping Carrier
orderid Optional Order Id

Transaction Response Variables

Standard Response

Variable Name Format Description

response 1/2/3 1 = Transaction Approved
2 = Transaction Declined
3 = Error in transaction data or system error
responsetext Textual response
authcode Transaction authorization code
transactionid Payment Gateway transaction id
avsresponse C AVS Response Code (See Appendix 1)
cvvresponse C CVV Response Code (See Appendix 2)
orderid The original order id passed in the transaction request.
response_code C Numeric mapping of processor responses (See Appendix 3)

Retail Data
Passing Retail Magnetic Stripe Data

The payment gateway supports passing of magnetic strip data collected

from a card reader.

Variable Name Format Description

track_1 raw Raw Magnetic Stripe Data
track_2 raw Raw Magnetic Stripe Data
track_3 raw Raw Magnetic Stripe Data

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 6

Testing Information
Transaction Testing Account

Transactions can be tested using one of two methods. First, transactions

can be submitted to any merchant account that is in test mode. Keep in
mind that if an account is in test mode, all valid credit cards will be
approved but no charges will actually be processed.

The Payment Gateway demo account can also be used for testing at any
time. Please use the following username and password for testing with
this account:

Username: demo
Password: password

Transaction POST URL

All transactions should be submitted to the following URL:

https://secure.networkmerchants.com/api/transact.php

This URL is the same for both Live and Test Mode environments.

Test Transaction Information

Test transactions can be submitted with the following information:

Visa 4111111111111111
MasterCard 5431111111111111
DiscoverCard 6011601160116611
American Express 341111111111111
Credit Card Expiration: 10/10
Amount > 1.00

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 7

 Triggering Errors in Test Mode
9 To cause a declined message, pass an amount less than 1.00.
9 To trigger a fatal error message, pass an invalid card number.
9 To simulate an AVS Match, pass 888 in the address1 field, 77777 for zip.
9 To simulate a CVV Match, pass 999 in the cvv field.

Examples
Direct Post Format

Data posted by merchant’s web site to Payment Gateway

username=demo&password=password&type=sale&ccnumber=4111111111
111111&ccexp=0711&cvv=999&amount=10.00

Response data returned to merchant’s web site in HTML body

response=1&responsetext=SUCCESS&authcode=123456&transactionid=2
81719471&avsresponse=&cvvresponse=M&orderid=&type=sale&response_code=100

Changelog

June 2007 Documented product_sku_x Variable

January 2007 Documented processor_id Variable
July 2006 Added Transaction Type Update
April 2006 Added Response Code Appendix
February 2006 Documented Browser Redirect Capability

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 8

Appendix 1 – AVS Response Codes
X Exact match, 9-character numeric ZIP
Y Exact match, 5-character numeric ZIP
D “
M “
A Address match only
B “
W 9-character numeric ZIP match only
Z 5-character Zip match only
P “
L “
N No address or ZIP match
C “
U Address unavailable
G Non-U.S. Issuer does not participate
I “
R Issuer system unavailable
E Not a mail/phone order
S Service not supported
0 AVS Not Available
O “
B “

Appendix 2 – CVV Response Codes

M CVV2/CVC2 Match
N CVV2/CVC2 No Match
P Not Processed
S Merchant has indicated that CVV2/CVC2 is not present
on card
U Issuer is not certified and/or has not provided Visa
encryption keys

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 9

Appendix 3 – response_code Lookup Table

Direct Post API Copyright 2001-2007 All Rights Reserved. Page | 10