Upload
kishor-nannaware
View
67
Download
0
Embed Size (px)
DESCRIPTION
Finance crisp for fund merchants
Citation preview
Merchant Interface Specification
Revision Date: 2/23/2012 3:37:00 PM
Proprietary & Confidential
Merchant Interface Specification
Proprietary & Confidential Page 2
Table of Contents
Introduction _______________________________________________________________________ 4
The “Transact” Web Services Group ___________________________________________________ 5
ProcessXXX Web Services _________________________________________________________________5 ProcessXXX Web Service Responses _______________________________________________________________ 8
ProcessCheck Web Service _________________________________________________________________9 ProcessCheckResponse _________________________________________________________________________ 13 ProcessCheckResponse – ERROR _________________________________________________________________ 14
ProcessDraft Web Service ________________________________________________________________15 ProcessDraft Web Service Responses ______________________________________________________________ 17
VoidTrx Web Service ____________________________________________________________________17 VoidTrx Response _____________________________________________________________________________ 17
CloneTrx Web Service ___________________________________________________________________18 CloneTrx Response ____________________________________________________________________________ 18
TransferTrx Web Service _________________________________________________________________19 TransferTrx Response __________________________________________________________________________ 20
GetTrxInfo Web Service __________________________________________________________________20 GetTrxInfo Response ___________________________________________________________________________ 21
GetTrxAuxInfo Web Service ______________________________________________________________22 GetTrxAuxInfo Response _______________________________________________________________________ 23
GetTrxList Web Service __________________________________________________________________24 GetTrxList Response ___________________________________________________________________________ 25
Valid ASCII Character Codes _____________________________________________________________26
Code Examples _________________________________________________________________________26 Calling ProcessFEE And Other Transact Web Services ________________________________________________ 26 Special considerations for ProcessCheck ____________________________________________________________ 28
The “Report” Web Services __________________________________________________________ 31
RequestReturns _________________________________________________________________________31 RequestReturns Response _______________________________________________________________________ 33 RequestReturnsResponse – ERROR _______________________________________________________________ 35
RequestTrxInfo _________________________________________________________________________36 RequestTrxInfo Response _______________________________________________________________________ 38 RequestTrxInfoResponse – ERROR _______________________________________________________________ 40
ReliaFunctions ____________________________________________________________________ 41
Overview ______________________________________________________________________________41
ABAChecksum _________________________________________________________________________41
SubscriberApplicationAdd ________________________________________________________________41
SubscriberApplicationBankAccountTypeList ________________________________________________42
SubscriberApplicationBusinessTypeListing __________________________________________________43
Merchant Interface Specification
Proprietary & Confidential Page 3
SubscriberApplicationChange _____________________________________________________________43
SubscriberApplicationDelete ______________________________________________________________43
SubscriberApplicationList ________________________________________________________________43
SubscriberApplicationMessages ___________________________________________________________43
SubscriberApplicationProgramSponsorList _________________________________________________43
SubscriberApplicationStatus ______________________________________________________________44
SubscriberApplicationStatusCodeListing ____________________________________________________44
ValidateAMEXCard _____________________________________________________________________44
ValidateMasterCard _____________________________________________________________________44
ValidateVisaCard _______________________________________________________________________44
Getting Started with Subscriptions _________________________________________________________44 Subscription Program Sponsors ___________________________________________________________________ 44 UserID and Password ___________________________________________________________________________ 45 Authorized Publishers __________________________________________________________________________ 45
Merchant Interface Specification
Proprietary & Confidential Page 4
Introduction
ReliaFund offers its merchants the ability to perform many transaction-related operations over the
internet through a selection of published web services. Through these web services merchants can
interact with ReliaFund’s ACH transaction processing queue and post transaction, perform transaction-
related operations, and retrieve reports.
ReliaFund’s web services are divided into three different groups based upon their functionality. These
groups are:
Transact – web services that focus on transaction processing, voiding, and status checking.
Reports – web services that return transaction reports based on search criteria.
ReliaFunctions – web services that provide utility and verification functions for check & credit card
processing and 3rd
party application integration with ReliaFund.
Merchant Interface Specification
Proprietary & Confidential Page 5
The “Transact” Web Services Group
The Transact set of web services focus on ACH and Check 21 electronic transaction processing. The
WDSL definitions of the web services available under this group can be found at:
https://payments.reliafund.com/transact/transact.asmx.
From this page you may view descriptions of the functions and perform testing.
All of the web services within the Transact group return (in one way or another) an XML node with a
name similar to <ProcessResult>. The format is as follows:
<*ProcessResult>
<ResultCode>…a result code indicating success or failure…</ResultCode>
<ResultMessage>…a verbose text message explaining the result…</ResultMessage>
<ResultData>
…additional tags—will vary…
</ResultData>
</*ProcessResult>
<ResultCode> and <ResultMessage> will always be returned and contain a message of either success or
failure while performing the specified operation.
The <ResultData> sub-node will contain different information for each web service, and will generally
only be populated if the specified operation was successful. Exact contents of <ResultData> is explained
below with each web service.
ProcessXXX Web Services
The “ProcessXXX” web services are ReliaFund’s solutions for simple, one-shot ACH transaction
processing for merchants. Each “ProcessXXX” web service corresponds to a specific ACH Standard
Entry Code (SEC), and requires only the parameters specific to that SEC. The following web services
are provided:
ProcessARC – Post an accounts receivable transaction
ProcessPPD – Post a pre-paid deposit transaction
ProcessTEL – Post a telephone-initiated transaction
ProcessWEB – Post a web-initiated transaction
ProcessPOP – Post a point-of-purchase transaction
ProcessFEE – Post a fee transaction against a merchant account
ProcessC21 – Post a Check21 draft transaction
ProcessBOC – Post a transaction from merchant back office conversion.
processCCD – Post a cash concentration or disbursement transaction.
ProcessRCK – Post a re-presentment of a previous ACH transaction
Merchant Interface Specification
Proprietary & Confidential Page 6
The “ProcessXXX” web services accept a serialized XML parameter list described below. Many of the
parameters are common to all of the web services, while other parameters are required only by certain
web services. Below is a grid showing the possible parameters and their individual requirements for
each “ProcessXXX” web service:
Required parameter - must be passed and contain a value
Optional parameter – must be passed but does not need to contain a value
Parameter not passed to this web service
Parameter
ProcessXXX, where XXX is…
ARC PPD TEL WEB POP FEE C21 BOC CCD RCK CIE
UserName Password TerminalID EntryDescription
TranType
AccountType
AccountSubType ABA Account Amount CheckNum MICR PayerName EffectiveDate CheckFront
CheckBack
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<TerminalID>
Merchant-designated terminal ID to assign to the transaction.
ReliaFund suggests merchants populate this field with a unique
terminal identifier for source tracking purposes.
<EntryDescription> A 10 character alphanumeric description of the transaction. Merchants
should use this field to denote the type of, or reason for, the transaction.
<TranType>
Indicate the type of transaction. valid values are:
0 – Debit (subtract funds)
1 – Credit (add funds)
2 – Prenote
For ProcessFEE, this is always a 1 (Credit)
For ProcessC21, this is always a 0 (Debit)
<AccountType> Indicate the type of bank account the transaction is targeting:
C – Checking Account
Merchant Interface Specification
Proprietary & Confidential Page 7
S – Savings Account
For POP, ARC, RCK and C21 transactions, this is always C (Checking
Account)
<AccountSubType>
Indicate the bank account sub-type:
P – Personal
B – Business
For POP, PPD, ARC and RCK transactions, this is always P (Personal)
For CCD and C21 transactions, this is always B (Business)
<ABA> The routing/transit # of the bank that the account is assigned to.
<Account> The account number to perform the transaction on
<Amount> The amount of the transaction. Must be zero if <TranType> is 2
(prenote)
<CheckNum>
Check # or merchant-assigned reference number for the transaction. For
transactions where a paper check is the source document the check
number must be used.
<MICR>
The complete Magnetic Ink Check Reader data line, which includes the
routing/transit # and Account #. Required for processing Check-
Present transactions.
<PayerName> Optional field indicating the authorizing source of the transaction.
<EffectiveDate>
Optional effective date of the transaction, up to 180 calendar days from
current date. If date falls on non-business day, date will be adjusted to
next business day.
If this parameter is left blank the default effective dates will be assigned
(next business day for debits, 3 business days out for credits).
<CheckFront> Base64 encoded TIFF-formatted check image (front)
<CheckBack> Base64 encoded TIFF-formatted check image (back)
Sample ProcessXXX XML message format
<ProcessFEE xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<TerminalID>1</TerminalID>
<EntryDescription>PRINTCHG</EntryDescription>
<AccountType>C</AccountType>
<AccountSubtype>B</AccountSubtype>
<ABA>123456780</ABA>
<Account>123456789012</Account>
<CheckNum>908</CheckNum>
<Amount>1.98</Amount>
<PayerName>Furry Fox Foods</PayerName>
</ProcessFEE>
Merchant Interface Specification
Proprietary & Confidential Page 8
ProcessXXX Web Service Responses
The “ProcessXXX” web services can respond with several different conditions:
1) Transaction has been approved – The transaction has been successfully posted to the ReliaFund
ACH processing queue and will be processed.
2) Transaction approved with caution – The transaction has been approved, but a cautionary alert is
included in the response to the merchant indicating a heightened awareness of risk concerning
the transaction.
3) Transaction is pending – The transaction needs to be inspected and approved manually before it
can be processed
4) Transaction was declined – The transaction failed to pass certain risk management rules and will
not be processed
5) Error – There was a problem with the transaction and it has been rejected.
Conditions 2 through 4 are generated through ReliaFund’s risk management profiles. For more
information concerning risk management profile configuration, contact your ReliaFund representative.
The following is a list of return parameters that the “ProcessXXX” web services can provide:
Parameter Value
<ResultCode>
The result code for the individual transaction.
00 – Transaction approved
01 – Transaction approved with caution notice
03 – Transaction is pending
99 – Transaction was declined
ERR – Error, transaction rejected
<ResultMessage> Text explanation for the particular ResultCode returned.
<RFID> The ReliaFund processing queue ID assigned to the transaction.
Note: the following parameters will only be returned if the transaction did not contain any errors.
<Amount> The amount of the transaction as given in the original transaction information.
<EffectiveDate> The date the transaction will post to the bank
<SettleDate> The date the transaction will settle to the merchant account
For each condition the “ProcessXXX” web service response XML will contain different parameter data.
Below are some examples of returned XML for each possible condition:
Condition #1 - Unable to authenticate:
<ProcessResult>
<ResultCode>ERR</ResultCode>
Merchant Interface Specification
Proprietary & Confidential Page 9
<ResultMessage>User name and/or password were not correct. Please correct the login credentials
and try again.
</ResultMessage>
</ResultData/>
</ProcessResult>
Condition #2 - Transaction contains errors. It will be logged and assigned an RFID value for future
referral purposes, but will not be processed:
<ProcessResult>
<ResultCode>ERR</ResultCode>
<ResultMessage>AccountType is not valid.</ResultMessage>
<ResultData>
<RFID>197093</RFID>
</ResultData>
</ProcessResult>
Note that multiple error conditions can be listed in the <ResultMessage>, for example:
<ResultMessage>Required fields missing: Amount. AccountSubType is not valid.</ResultMessage>
Condition #3 – Transaction successfully inserted into the ProcessQ for processing:
<ProcessResult>
<ResultCode>00</ResultCode>
<ResultMessage>Approval</ResultMessage>
<ResultData>
<Amount>106.95</Amount>
<EffectiveDate>9/17/2007</EffectiveDate>
<SettleDate>9/17/2007</SettleDate>
<RFID>197086</RFID>
</ResultData>
</ProcessResult>
ProcessCheck Web Service
This is ReliaFund’s generic ACH and Check21 processing web service. This web service can accept all
standard ACH transaction types as well as Check 21 transactions and supports the following features
above and beyond the simpler ProcessXXX web services:
Batch processing – Multiple ACH or Check21 transactions can be passed and process with a
single call
Auxiliary merchant-defined data can be passed and stored with each transaction for later retrieval
Merchant Interface Specification
Proprietary & Confidential Page 10
This web service is provided for backwards compatibility for merchants who are already familiar with
ReliaFund’s ProcessChecks web service available under the Check21Processor collection, or merchants
who need the extra benefits of batch processing and auxiliary field data support.
ProcessCheck functions identically to original ProcessChecks web service, but with the enhanced logic
that has been coded into the new ProcessXXX web services.
Rather than a list of serialized XML parameters, the ProcessCheck web service accepts a single string
parameter named “sxml”. This parameter consists of a complex XML message consisting of multiple
nodes. The basic structure of the XML is:
<ProcessCheck>
...User-specific tags...
<Batch ...batch-specific attributes...>
<Transaction>
...Transaction-specific tags...
</Transaction>
<Transaction>
...Transaction-specific tags...
</Transaction>
...
</Batch>
</ProcessCheck>
The allowed user-specific tags are as follows:
Tag Description
<UserName> Required. User name assigned in the payment server.
<Password> Required. Password for the user name assigned in the payment server.
<TerminalID>
Merchant-designated terminal ID to assign to the transaction.
ReliaFund suggests merchants populate this field with a unique
terminal identifier for source tracking purposes.
The allowed batch-specific attributes are as follows:
Attribute Description
RecordCount Required. The number of transactions in the batch.
BatchTotal Required. The total amount for the transactions in the batch
The allowed transaction-specific tags are as follows. Requirements are based on transaction type and
follow the same rules as the “ProcessXXX” web services:
Tag Description
<TransactionID> Optional merchant-designated transaction ID. ReliaFund suggests
merchants populate this field with an identification number for tracking
Merchant Interface Specification
Proprietary & Confidential Page 11
purposes.
<Service>
The type of operation to perform. Valid values are:
ADD – Add new transaction to processing queue
TEST – A special mode merchants can use to test their XML
messages and verify the validity of their data to ReliaFund’s
processing system. This operation will not post a transaction to the
processing queue or perform a duplicate transaction check.
<StandardEntryCode>
The code indicating the type of transaction. Common values are:
ARC – Accounts Receivable
PPD – Pre-arranged Payment And Deposit
TEL – Telephone-initiated Transaction
WEB – Internet-initiated Transaction
POP – Point-of-purchase Transaction
FEE – Fee Transaction
C21 – Check 21
<EntryDescription> A 10 character alphanumeric description of the transaction. Merchants
should use this field to denote the type or reason for the transaction.
<TranType>
Indicate the type of transaction. valid values are:
0 – Debit
1 – Credit (not valid for Check21 transactions)
2 – Prenote (not valid for Check21 transactions)
<AccountType>
Indicate the type of bank account the transaction is targeting:
C – Checking Account
S – Savings Account
<AccountSubType>
Indicate the bank account sub-type:
P – Personal
B – Business
<ABA> The routing/transit # of the bank that the account is assigned to.
<Account> The account number to perform the transaction on
<Amount> The amount of the transaction. Must be zero if <TranType> is 2
(prenote)
<CheckNum>
Check # or merchant-assigned reference number for the transaction. For
transactions where a paper check is the source document the check
number must be used.
<MICR>
The complete Magnetic Ink Check Reader data line, which includes the
routing/transit # and Account #. Required for Check21 transactions
only.
<PayerName> The name appearing on the check or the name of the person authorizing
the transaction.
<Address>
Optional data fields for holding payer information <City>
<State>
<ZIP>
Merchant Interface Specification
Proprietary & Confidential Page 12
<AUX_1>
Optional auxiliary data fields. May contain any optional alphanumeric
data user chooses (Maximum length = 100 characters).
<AUX_2>
<AUX_3>
<AUX_4>
<AUX_5>
<AUX_6>
<AUX_7>
<AUX_8>
<AUX_9>
<AUX_10>
<CheckFront> Base64-encoded TIFF-formatted check image (front)
<CheckBack> Base64-encoded TIFF-formatted check image (back)
Sample ProcessCheck XML message format <ProcessCheck>
<UserName>testun</UserName>
<Password>testpw</Password>
<TerminalID>2</TerminalID>
<Batch RecordCount='1' BatchTotal='52.08'>
<Transaction>
<TransactionID>1</TransactionID>
<Service>ADD</Service>
<StandardEntryCode>C21</StandardEntryCode>
<EntryDescription>Premium</EntryDescription>
<TranType>0</TranType>
<AccountType>C</AccountType>
<AccountSubType>P</AccountSubType>
<ABA>063108680</ABA>
<Account>12345678</Account>
<Amount>52.08</Amount>
<CheckNum>1147</CheckNum>
<MICR>06310868012345678</MICR>
<PayerName>Joe O'Somebody</PayerName>
<Address>123 Somewhere</Address>
<City>Tampa</City>
<State>FL</State>
<ZIP>33634</ZIP>
<AUX_1>0577231</AUX_1>
<AUX_2>29AB</AUX_2>
<CheckFront></CheckFront>
<CheckBack></CheckBack>
</Transaction>
</Batch>
</ProcessCheck>
Merchant Interface Specification
Proprietary & Confidential Page 13
ProcessCheckResponse
Upon successful submission and insertion of a batch of transactions, the ProcessCheck web service will
return a single string containing a complex XML message containing response information for each
transaction submitted. The format of this XML message is:
<ProcessCheckResponse>
... batch total information ...
<Batch>
<Transaction>
...information for transaction...
</Transaction>
<Transaction>
...information for transaction...
</Transaction>
...
</Batch>
</ProcessCheckResponse>
The batch total information tags include:
Parameter Value
<TransCountReceived> The total number of transactions received.
<TransCountAccepted> The number of valid transactions accepted
<TransCountNotAccepted> The number of rejected transactions.
<AcceptedTotal> The total dollar amount for all accepted transactions.
<NotAcceptedTotal> The total dollar amount for all rejected transactions.
For each transaction received, the response XML will contain a <transaction> node with these values:
Parameter Value
<TransactionID> The transaction ID as given in the original transaction information
<Amount> The amount of the transaction as given in the original transaction information.
<ResultCode>
The result code for the individual transaction.
00 – Transaction approved
01 – Transaction approved with caution notice
03 – Transaction is pending
99 – Transaction was declined
ERR – Error, transaction rejected
<ResultMessage> Text explanation for the particular ResultCode returned.
<RFID> The ReliaFund processing queue ID assigned to the transaction.
Note: the following parameters will only be returned if the transaction did not contain any errors.
<EffectiveDate> The date the transaction will post to the bank.
Merchant Interface Specification
Proprietary & Confidential Page 14
<SettleDate> The date the transaction will settle to the merchant account.
Sample ProcessCheckResponse XML message format <ProcessCheckResponse>
<TransCountReceived>1</TransCountReceived>
<TransCountAccepted>1</TransCountAccepted>
<TransCountNotAccepted>0</TransCountNotAccepted>
<AcceptedTotal>52.08</AcceptedTotal>
<NotAcceptedTotal></NotAcceptTotal>
<Batch>
<Transaction>
<TransactionID>1</TransactionID>
<Amount>52.08</Amount>
<ResultCode>00</ResultCode>
<ResultMessage>Approved</ResultMessage>
<RFID>343</RFID>
<EffectiveDate>8/23/2006</EffectiveDate>
<SettleDate>8/25/2006</SettleDate>
</Transaction>
</Batch>
</ProcessCheckResponse>
ProcessCheckResponse – ERROR
If an error occurs and the ProcessCheck web service is unable to process the incoming XML message
from the merchant, it will return a single string parameter containing an error response formatted into an
XML message in the following format:
<ProcessCheckResponse>
<ResultCode>ERR</ResultCode>
<ResultMessage>Error Message</ResultMessage>
</ProcessCheckResponse>
The following table lists some possible errors that can be returned by ProcessCheck:
ResultCode ResultMessage
ERR XML document does not contain child nodes.
ERR Invalid user name or password.
ERR User name and/or password were not correct. Please
correct the login credentials and try again.
ERR Batch section is missing. Please correct the XML
transmission document.
ERR Batch does not contain child nodes.
ERR Transactions are missing.
Merchant Interface Specification
Proprietary & Confidential Page 15
ProcessDraft Web Service
The ProcessDraft web service can be thought of as a “Paperless Check21” operation. This web service is
similar to the ProcessC21 web service and inserts a Check21 transaction into ReliaFund’s processing
queue. The difference is that ProcessDraft will also create a check draft image (front and back) to
accompany the transaction. This is useful when a merchant wants to perform a Check21 transaction but
does not have access to the physical paper draft for the transaction, such as a phone-in transaction. The
same rules apply to ProcessDraft-generated transactions that apply to a normal Check21 transaction.
The draft images will be generated using the account information provided by the web service
parameters and inserted directly into ReliaFund’s processing queue. Additional bank information will be
pulled from ReliaFund’s processing database. If ReliaFund has no record of the bank the draft is to be
drawn upon, the transaction will be declined and a draft will not be generated.
The draft images generated can later be viewed via ReliaFund’s website reports.
The ProcessDraft web service accepts a serialized XML parameter list described below:
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<TerminalID>
Merchant-designated terminal ID to assign to the transaction.
ReliaFund suggests merchants populate this field with a unique
terminal identifier for source tracking purposes.
<ABA> The routing/transit # of the bank that the account is assigned to.
<Account> The account number to perform the transaction on
<Amount> The amount of the transaction. Must be zero if <TranType> is 2
(prenote)
<CheckNum> A merchant assigned reference number for the transaction.
<PayerName>
The name, complete address, and contact phone number of the owner
of the checking account being debited. These parameters will be
printed in the upper left corner of the draft generated.
<PayerAddress1>
<PayerAddress2>
<PayerCity>
<PayerState>
<PayerZip>
<PayerPhone>
<AmountDescription> Description of the transaction to be printed on the check draft’s
MEMO line.
<CSPhone> Customer Service contact phone # of the merchant initiating the
transaction
Merchant Interface Specification
Proprietary & Confidential Page 16
<InvoiceNumber> Optional merchant invoice # to be included in the information printed
on the check draft.
<AuthorizationNumber> Optional merchant authorization # to be included in the information
printed on the check draft.
Sample ProcessDraft XML message format
<ProcessDraft xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<TerminalID>1</TerminalID>
<ABA>123456780</ABA>
<Account>123456789012</Account>
<CheckNum>1002</CheckNum>
<Amount>22.94</Amount>
<PayerName>Joe Smith</PayerName>
<PayerAddress>123 Some Street</PayerAddress>
<PayerAddress2></PayerAddress2>
<PayerCity>Minneapolis</PayerCity>
<PayerState>MN</PayerState>
<PayerZip>55401</PayerZip>
<PayerPhone>612-555-1212</PayerPhone>
<AmountDescription>Subscription Renewal through 01/2009</AmountDescription>
<CSPhone>(800) 555-1212 </CSPhone>
<InvoiceNumber>A-20185-33129-7</InvoiceNumber>
<AuthorizationNumber>010523</AuthorizationNumber>
</ProcessDraft>
The front draft image that would be generated for this transaction would look similar to the following:
Merchant Interface Specification
Proprietary & Confidential Page 17
ProcessDraft Web Service Responses
The format of the ProcessDraft web service response is the same as the “ProcessXXX” web services’
(See ProcessXXX Web Service Responses).
It should be noted that due to the added overhead of generating a draft’s front and back images and
converting them to proper ICL format, ProcessDraft can take slightly more time (between 5 and 10
seconds) to generate a response message to the merchant.
VoidTrx Web Service
This web services allows a merchant to void a transaction that was previously posted to ReliaFund’s
ACH processing queue. The RFID of the transaction (received in the response messages of the
ProcessCheck or ProcessXXX web services) is passed to VoidTrx. A result code will be passed back
indicating the success or failure of the void operation.
The VoidTrx web service accepts a serialized XML parameter list described below:
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<RFID> The ReliaFund processing queue ID of the transaction to void
Sample VoidTrx XML message format
<VoidTrx xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<RFID>197204</RFID>
</VoidTrx>
VoidTrx Response
The VoidTrx web service will respond with a <SimpleProcessResult> packet with the following
parameters:
Parameter Value
<ResultCode>
The result code for the void operation.
00 – Success, transaction has been voided.
ERR – Void failed. See <ResultMessage> for further details.
<ResultMessage> This will either be the word “Voided” or an error message explaining why the
transaction was not voided.
Merchant Interface Specification
Proprietary & Confidential Page 18
Sample VoidTrx Response XML:
<SimpleProcessResult>
<ResultCode>00</ResultCode>
<ResultMessage>Voided</ResultMessage>
</SimpleProcessResult>
CloneTrx Web Service
This web services allows a merchant to clone (duplicate) a previously processed transaction. The cloned
transaction will carry all of the ACH information from the original transaction with optional new
amount and effective date. The RFID of the transaction to clone (received in the response messages of
the ProcessCheck or ProcessXXX web services) is passed to CloneTrx. A result code and possible new
transaction information will be passed back indicating the success or failure of the clone operation.
The CloneTrx web service accepts a serialized XML parameter list described below:
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<RFID> The ReliaFund processing queue ID of the transaction to void
<CheckNum>
Check # or merchant-assigned reference number for the transaction. For
transactions where a paper check is the source document the check
number must be used.
<Amount> Optional new amount to assign to the cloned transaction. If not
specified the original transaction’s amount will be used.
<EffectiveDate> Optional effective date to assign to the cloned transaction. If this
parameter is left blank the default effective dates will be assigned.
Sample CloneTrx XML message format
<CloneTrx xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<RFID>197204</RFID>
<CheckNum>10085</CheckNum>
<EffectiveDate><EffectiveDate>
</CloneTrx>
CloneTrx Response
The format of the CloneTrx web service response is the same as the “ProcessXXX” web services’ (See
ProcessXXX Web Service Responses).
Merchant Interface Specification
Proprietary & Confidential Page 19
TransferTrx Web Service
This web service allows one ReliaFund user to transfer money to or from a second ReliaFund user
without having to reveal the second user’s account information to the first user. Transfers require
knowing the second user’s UserName and Password. Both users will be authenticated and must be active
and set up properly for a transfer to be performed.
Transfers can be done via ACH or Check21 methods. When Check21 methods are used, a check draft
image will be created to accompany the transaction.
There are two types of transfers: PULL and PUSH:
Transfer Type PULL PUSH
Allowed SEC PPD, C21 PPD, CIE C21
Example 1. Joe is the merchant and
needs to get (PULL) money
from Frank.
2. Joe gets the okay from
Frank to do a "PULL"
(meaning Joe's account will
PULL the funds from
Frank’s with a debit
transaction).
3. TransferTrx generates a
debit transaction created by
Joe and using Frank's
account info.
4. Reliafund creates the
settlement credit to Joe’s
account in the normal way
1. Joe is the merchant and
need to send (PUSH) money
to Frank.
2. Joe gets the okay from
Frank to do a "PUSH"
(meaning Joe’s account will
PUSH the funds to Frank’s
with a credit transaction).
3. TransferTrx generates a
credit transaction created by
Joe and using Frank's
account info.
4. Reliafund creates the
settlement debit credit to
Joes account in the normal
way
1. Joe is the merchant and
need to send (PUSH) money
to Frank.
2. Joe gets the okay from
Frank to do a "PUSH"
(because Check21
transactions must be debits,
Frank’s account will actually
PULL the funds from Joe’s
with a debit transaction).
3. TransferTrx generates a
debit transaction created by
Frank and using Joe’s
account info.
4. Reliafund creates the
settlement credit to Frank’s
account in the normal way
ACH transactions generated for transfers will have an EntryDescription field of “TRANSFER”.
The TransferTrx web service accepts a serialized XML parameter list described below:
Parameter Description
<FromUserName> User name of the user to transfer funds from
<FromPassword> Password for the user to transfer funds from
<ToUserName> User name of the user to transfer funds to
<ToPassword> Password for the user to transfer funds to
Merchant Interface Specification
Proprietary & Confidential Page 20
<Service>
Type of transfer:
PULL – Collect (pull) funds from the FROM user to the TO user
PUSH – Send (push) funds from the FROM user to the TO user
<StandardEntryCode>
The code indicating the type of transaction to use for the transfer.
Allowed values are:
PPD – For PUSH and PULL
CIE – For PUSH only
C21 – For PUSH and PULL
<EntryDescription> A 10 character alphanumeric description of the transaction. Merchants
should use this field to denote the type of, or reason for, the transaction.
<CheckNun>
Check # or merchant-assigned reference number for the transaction. For
transactions where a paper check is the source document the check
number must be used.
<Amount> Amount of the transfer
Sample TransferTrx XML message format
<TransferTrx xmlns="http://service.Reliafund.com/Transact">
<FromUserName>demo</FromUserName>
<FromPassword>test</FromPassword>
<ToUserName>demo2</ToUserName>
<ToPassword>test2</ToPassword>
<Service>PULL</Service>
<StandardEntryCode>PPD</StandardEntryCode>
<EntryDescription>TRANSFER</EntryDescription>
<CheckNum>10311</CheckNum>
</TransferTrx>
TransferTrx Response
The format of the TransferTrx web service response is the same as the “ProcessXXX” web services’
(See ProcessXXX Web Service Responses).
GetTrxInfo Web Service
This web services allows a merchant to retrieve the current processing status information for a
previously submitted transaction. The RFID of the transaction (received in the response messages of the
ProcessCheck or ProcessXXX web services) is passed to GetTrxInfo. A transaction information packet
will be passed back.
The GetTrxInfo web service accepts a serialized XML parameter list described below:
Parameter Description
Merchant Interface Specification
Proprietary & Confidential Page 21
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<RFID> The ReliaFund processing queue ID of the transaction
Sample GetTrxInfo XML message format
<GetTrxInfo xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<RFID>197204</RFID>
</GetTrxInfo>
GetTrxInfo Response
The GetTrxInfo web service responds with a <ExtendedProcessResult> packet containing detailed
information regarding the transaction referenced by the RFID:
Parameter Value
<ResultCode>
The result code for the void operation.
00 – Success, transaction information retrieved
ERR – There was an error processing the request. See <ResultMessage> for
further details.
<ResultMessage> This will either be the word “Retrieved” or an error message explaining why the
request could not be processed
Note: the following parameters will only be returned if the transaction was found
<Amount> The amount of the transaction
<EffectiveDate> The date the transaction will post to the bank
<SettleDate> The date the transaction will settle to the merchant account
<RFID> The ReliaFund processing queue ID assigned to the transaction.
<AuthCode> This is the original <ResultCode> for the transaction that was passed back to the
merchant from the ProcessCheck or “ProcessXXX” web service.
<AuthText> This is the original <ResultMessage) for the transaction that was passed back to the
merchant from the ProcessCheck or “ProcessXXX” web service.
<StandardEntryCode> The ACH code indicating the type of transaction, “C21” for Check21 transactions.
<TransactionType> “Credit”, ‘Debit” or “Prenote”
<ABA> Routing number with all but the last 4 digits masked
<Account> Account number with all but the last 4 digits masked
<CheckNum> Check # or merchant-assigned reference number
<TransactionDate> The date & time the transaction was submitted to ReliaFund
Merchant Interface Specification
Proprietary & Confidential Page 22
<ProcessedDate> The date & time the transaction was processed for settlement
<ProcessState> This is the state of the transaction within ReliaFund’s processing queue
<ProcessStatus> This is the transaction’s current processing status within ReliaFund’s processing
queue
<RFReturnID> If the transaction has been returned, this tag will contain the ID of the return.
Otherwise the tag will be empty.
Note: the following tags will only be returned of <RFReturnID> contains a value.
ReturnDate This is the date & time notice was received that the item was returned
ReturnReasonCode The R00 – R89 ACH reason code for why the transaction was returned
Sample GetTrxInfo Response XML:
<ExtendedProcessResult>
<ResultCode>00</ResultCode>
<ResultMessage>Retrieved</ResultMessage>
<ResultData>
<Amount>30</Amount>
<EffectiveDate>5/1/2008</EffectiveDate>
<SettleDate>4/14/2008</SettleDate>
<RFID>197323</RFID>
<AuthCode>00</AuthCode>
<AuthText>Approval</AuthText>
<StandardEntryCode>PPD</StandardEntryCode>
<TransactionType>Credit</TransactionType>
<ABA>*****0019</ABA>
<Account>**1111</Account>
<CheckNum>3010</CheckNum>
<TransactionDate>4/11/2008 10:36:18 AM</TransactionDate>
<ProcessedDate/>
<ProcessState>Void</ProcessState>
<ProcessStatus>Preliminary</ProcessStatus>
<ReturnID/>
</ResultData>
</ExtendedProcessResult>
GetTrxAuxInfo Web Service
This web services allows a merchant to retrieve any merchant-defined auxiliary data stored for a
transaction previously submitted via the ProcessCheck web service. The RFID of the transaction
(received in the response messages of the ProcessCheck web services) is passed to GetTrxAuxInfo. A
transaction information packet will be passed back.
Merchant Interface Specification
Proprietary & Confidential Page 23
The GetTrxAuxInfo web service accepts a serialized XML parameter list described below:
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<RFID> The ReliaFund processing queue ID of the transaction
Sample GetTrxAuxInfo XML message format
<GetTrxAuxInfo xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<RFID>197204</RFID>
</GetTrxAuxInfo>
GetTrxAuxInfo Response
The GetTrxAuxInfo web service responds with a <AuxProcessResult> packet containing any merchant-
defined auxiliary data stored for the transaction referenced by the RFID:
Parameter Value
<ResultCode>
The result code for the void operation.
00 – Success, transaction information retrieved
ERR – There was an error processing the request. See <ResultMessage> for
further details.
<ResultMessage> This will either be the word “Retrieved” or an error message explaining why the
request could not be processed
Note: the following parameters will only be returned if the transaction was found
<TransactionID> Merchant-designated transaction ID
<Address>
Payer information data field values <City>
<State>
<ZIP>
<AUX_1>
Auxiliary data field values
<AUX_2>
<AUX_3>
<AUX_4>
<AUX_5>
<AUX_6>
Merchant Interface Specification
Proprietary & Confidential Page 24
<AUX_7>
<AUX_8>
<AUX_9>
<AUX_10>
Sample GetTrxAuxInfo Response XML:
<AuxProcessResult>
<ResultCode>00</ResultCode>
<ResultMessage>Retrieved</ResultMessage>
<ResultData>
<Address>123 Front Street</Address>
<City>AnyTown</City>
<State>MN</State>
<Zip>55113</Zip>
<AUX_1>002188531</AUX_1>
<AUX_2>11/20/2009 12:35:00 PM</AUX_2>
<AUX_3/>
<AUX_4/>
<AUX_5/>
<AUX_6/>
<AUX_7/>
<AUX_8/>
<AUX_9/>
<AUX_10/>
</ResultData>
</AuxProcessResult>
GetTrxList Web Service
This web services allows a merchant to retrieve the last X number of RFIDs received by ReliaFund for
processing, either from the web services, from uploaded files, or from manually generated items from
ReliaFund. The merchant can specify the number of RFIDs returned, from 1 to 999, and to return either
all RFID’s or only RFID’s that have been accepted for processing.
The GetTrxList web service accepts a serialized XML parameter list described below:
Parameter Description
<UserName> User name assigned in the payment server.
<Password> Password for the user name assigned in the payment server.
<TrxCount> The number of RFIDs to return, from 1 to 999
Merchant Interface Specification
Proprietary & Confidential Page 25
<ReturnAll>
0 – Will return only RFIDs associated with successful (non-error)
transactions
1 – Will return everything
Sample GetTrxInfo XML message format
<GetTrxList xmlns="http://service.Reliafund.com/Transact">
<UserName>demo</UserName>
<Password>test</Password>
<TrxCount>5</TrxCount>
<ReturnAll>1</ReturnAll>
</GetTrxList>
GetTrxList Response
The GetTrxList web service responds with a <ProcessListResult> packet containing the list of RFIDs
requested:
Parameter Value
<ResultCode>
The result code for the void operation.
00 – Success, transaction information retrieved
ERR – There was an error processing the request. See <ResultMessage> for
further details.
<ResultMessage> This will either be the word “Retrieved” or an error message explaining why the
request could not be processed.
Note: the following parameters will only be returned if ResultCode = 00
<RFID> RFID of a transaction received by ReliaFund
Sample GetTrxList Response XML:
<ProcessListResult>
<ResultCode>00</ResultCode>
<ResultMessage>Retrieved</ResultMessage>
<RFIDList>
<string>197578</string>
<string>197577</string>
<string>197575</string>
<string>197573</string>
<string>197570</string>
</RFIDList>
</ProcessListResult>
Merchant Interface Specification
Proprietary & Confidential Page 26
Valid ASCII Character Codes
All alphanumeric fields may contain any ASCII characters from 0x20 (32) through 0x7F (127).
Proper character encoding of parameter values according to the RFC 1738 Uniform Resource Locators
(URL) specifications must be adhered to depending on how the merchant interfaces with the web
services.
Code Examples
This section includes example code for accessing some of the Transact web services.
Because merchant development environments can vary greatly, we have provided examples using
several different techniques:
HTTP POST using the MSXML 2.0 object Microsoft.XMLHTTP
SOAP 1.1 using the MSXML 3.0 object MSXML2.ServerXMLHTTP
.NET WebReference using Microsoft Visual Studio 2005
Note that the Microsoft.XMLHTTP object can also be used to implement the SOAP 1.1 interface.
All code samples presented below were written in Visual Basic .NET. For merchants using VB6, The
HTTP POST method can be converted to VB6 with only some minor syntax adjustments. To access
Reliafund's web services via SOAP access in VB6, we suggest using the free SOAP Toolkit from
Microsoft and using the MSSOAP.SoapClient30 object.
Calling ProcessFEE And Other Transact Web Services
The method for calling ProcessFEE is similar to almost every web service in the Transact group, with
the exception of ProcessCheck (more on this later). ProcessFEE was chosen for an example because it
has the least number of parameters of any of the “ProcessXXX” web services, but still shows how to use
these important services.
For “ProcessXXX” web service requiring check images as parameters, the image file data is passed as a
Base64-encoded ASCII string. Note that when using the HTTP POST method, the ASCII string will also
need to be encoded to be URL-friendly, meaning all “+” characters will need to be converted to ‘%2b’
strings. This can be done in Visual Basic .NET using the HTTPUtility.UrlEncode() method in the
System.Web namespace.
HTTP POST method using MSXML 2.0 object Microsoft.XMLHTTP
Dim xmlText As String
xmlText = "&UserName=demo" & _
Merchant Interface Specification
Proprietary & Confidential Page 27
"&Password=test" & _
"&TerminalID=2" & _
"&EntryDescription=Premium" & _
"&AccountType=C" & _
"&AccountSubType=P" & _
"&ABA=123456780" & _
"&Account=123456789012" & _
"&CheckNum=1147" & _
"&Amount=52.08" & _
"&PayerName=John Smith"
Dim ObjXml As Object
ObjXml = CreateObject("Microsoft.XMLHTTP")
ObjXml.open("Post", _
"https://payments.reliafund.com/transact/transact.asmx/ProcessFEE", False)
ObjXml.setRequestHeader("Content-type", "application/x-www-form-urlencoded")
ObjXml.setRequestHeader("Content-length", Len(xmlText))
ObjXml.send(Convert.ToString(xmlText))
MsgBox(ObjXml.ResponseText)
SOAP 1.1 method using MSXML 3.0 object MSXML2.ServerXMLHTTP
Dim xmlText As String
xmlText = "<?xml version=""1.0"" encoding=""utf-8""?>" & _
"<soap:Envelope xmlns:xsi=""http://www.w3.org/2001/XMLSchema-
instance"" " & _
"xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" " & _
"xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/"">" & _
"<soap:Body>" & _
"<ProcessFEE xmlns=""http://service.Reliafund.com/Transact"">" & _
"<UserName>demo</UserName>" & _
"<Password>test</Password>" & _
"<TerminalID>2</TerminalID>" & _
"<EntryDescription>Premium</EntryDescription>" & _
"<AccountType>C</AccountType>" & _
"<AccountSubType>P</AccountSubType>" & _
"<ABA>123456780</ABA>" & _
"<Account>123456789012</Account>" & _
"<Amount>52.08</Amount>" & _
"<CheckNum>1147</CheckNum>" & _
"<PayerName>John Smith</PayerName>" & _
"</ProcessFEE>" & _
"</soap:Body>" & _
"</soap:Envelope>"
Dim ObjXml As Object
ObjXml = CreateObject("msxml2.serverXMLHTTP")
ObjXml.open("POST", _
"https://payments.reliafund.com/transact/transact.asmx", False)
ObjXml.setRequestHeader("Content-Type", "text/xml; charset=utf-8")
ObjXml.setRequestHeader("Content-Length", Len(xmlText))
ObjXml.setRequestHeader("SOAPAction", _
"http://service.Reliafund.com/Transact/ProcessFEE")
ObjXml.send(Convert.ToString(xmlText))
MsgBox(ObjXml.ResponseText)
Merchant Interface Specification
Proprietary & Confidential Page 28
.NET WebReference to “http://payments.reliafund.com/transact/transact.asmx”
Dim ReliafundServices As New WebReference.Transact
Dim ServiceResult As WebReference.ProcessResult
ServiceResult = ReliafundServices.ProcessFEE( _
"demo", "test", "1", "Premium", "C", "P", "123456780", "123456789012", _
"1147", "52.08", "John Smith")
MsgBox(ServiceResult.ResultCode + Chr(13) + ServiceResult.ResultMessage)
Special considerations for ProcessCheck
Because ProcessCheck accepts as its only parameter (called sxml) an embedded XML document, and
returns a raw XML fragment in response, formatting the parameters for and interpreting the response
value from this web service is more difficult than the other web services in the Transact group. Specific
examples for calling ProcessCheck have been presented below.
HTTP POST method using MSXML 2.0 object Microsoft.XMLHTTP
Dim xmlText As String
xmlText = "sxml=" & _
"<ProcessCheck>" & _
"<UserName>demo</UserName>" & _
"<Password>test</Password>" & _
"<TerminalID>2</TerminalID>" & _
"<Batch RecordCount='1' BatchTotal='52.08'>" & _
"<Transaction>" & _
"<TransactionID>1</TransactionID>" & _
"<Service>Add</Service>" & _
"<StandardEntryCode>FEE</StandardEntryCode>" & _
"<EntryDescription>Premium</EntryDescription>" & _
"<TranType>0</TranType>" & _
"<AccountType>C</AccountType>" & _
"<AccountSubType>P</AccountSubType>" & _
"<ABA>123456780</ABA>" & _
"<Account>123456789012</Account>" & _
"<Amount>52.08</Amount>" & _
"<CheckNum>1147</CheckNum>" & _
"<PayerName>Joe Smith</PayerName>" & _
"</Transaction>" & _
"</Batch>" & _
"</ProcessCheck>"
Dim ObjXml As Object
ObjXml = CreateObject("Microsoft.XMLHTTP")
ObjXml.open("Post", _
"https://payments.reliafund.com/transact/transact.asmx/ProcessCheck",
False)
ObjXml.setRequestHeader("Content-type", "application/x-www-form-urlencoded")
ObjXml.setRequestHeader("Content-length", Len(xmlText))
ObjXml.send(Convert.ToString(xmlText))
MsgBox(ObjXml.ResponseText)
SOAP 1.1 method using MSXML 3.0 object MSXML2.ServerXMLHTTP
Merchant Interface Specification
Proprietary & Confidential Page 29
Note that because ProcessCheck’s parameter is an embedded XML document, the characters in that
document need to be converted to HTML-friendly characters when embedding that parameter into a
SOAP packet. Thus, any “<” and “>” characters need to be converted to “<” and “>” respectively.
Dim xmlText As String
xmlText = "<?xml version='1.0' encoding='UTF-8'?>" & _
"<soap:Envelope xmlns:xsi=""http://www.w3.org/2001/XMLSchema-" & _
"instance"" xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" " & _
"xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/"">" & _
"<soap:Body>" & _
"<ProcessCheck xmlns=""http://service.Reliafund.com/Transact"">" & _
"<sxml>" & _
"<ProcessCheck>" & _
"<UserName>demo</UserName>" & _
"<Password>test</Password>" & _
"<TerminalID>2</TerminalID>" & _
"<Batch RecordCount='1' BatchTotal='52.08'>" & _
"<Transaction>" & _
"<TransactionID>1</TransactionID>" & _
"<Service>Add</Service>" & _
"<StandardEntryCode>FEE</StandardEntryCode>" & _
"<EntryDescription>Premium</EntryDescription>" & _
"<TranType>0</TranType>" & _
"<AccountType>C</AccountType>" & _
"<AccountSubType>P</AccountSubType>" & _
"<ABA>123456780</ABA>" & _
"<Account>123456789012</Account>" & _
"<Amount>52.08</Amount>" & _
"<CheckNum>1147</CheckNum>" & _
"<PayerName>Joe Smith</PayerName>" & _
"</Transaction>" & _
"</Batch>" & _
"</ProcessCheck>" & _
"</sxml>" & _
"</ProcessCheck>" & _
"</soap:Body>" & _
"</soap:Envelope>"
Dim ObjXml As Object
ObjXml = CreateObject("msxml2.serverXMLHTTP")
ObjXml.open("POST", _
"https://payments.reliafund.com/transact/transact.asmx", False)
ObjXml.setRequestHeader("Content-Type", "text/xml; charset=utf-8")
ObjXml.setRequestHeader("Content-Length", Len(xmlText))
ObjXml.setRequestHeader("SOAPAction", _
"http://service.Reliafund.com/transact/ProcessCheck")
ObjXml.send(Convert.ToString(xmlText))
MsgBox(ObjXml.ResponseText)
.NET WebReference to “http://payments.reliafund.com/transact/transact.asmx”
Dim xmlText As String
Dim xmlResponseText As String
xmlText = "<ProcessCheck>" & _
"<UserName>demo</UserName>" & _
"<Password>test</Password>" & _
"<TerminalID>2</TerminalID>" & _
"<Batch RecordCount='1' BatchTotal='52.08'>" & _
"<Transaction>" & _
Merchant Interface Specification
Proprietary & Confidential Page 30
"<TransactionID>1</TransactionID>" & _
"<Service>Add</Service>" & _
"<StandardEntryCode>FEE</StandardEntryCode>" & _
"<EntryDescription>Premium</EntryDescription>" & _
"<TranType>0</TranType>" & _
"<AccountType>C</AccountType>" & _
"<AccountSubType>P</AccountSubType>" & _
"<ABA>123456780</ABA>" & _
"<Account>123456789012</Account>" & _
"<Amount>52.08</Amount>" & _
"<CheckNum>1147</CheckNum>" & _
"<PayerName>Joe Smith</PayerName>" & _
"</Transaction>" & _
"</Batch>" & _
"</ProcessCheck>"
Dim ReliafundServices As New WebReference.Transact
xmlResponseText = ReliafundServices.ProcessCheck(Convert.ToString(xmlText))
MsgBox(xmlResponseText)
Merchant Interface Specification
Proprietary & Confidential Page 31
The “Report” Web Services
The Report set of web services focus on retrieval of transaction processing status and return information.
The root URL for the WDSL definitions of the web services available under this group is:
https://payments.reliafund.com/report/report.asmx.
From this page you may view descriptions of the functions and perform testing.
RequestReturns
The RequestReturns Service is used to request returns for any transactions that have been processed by
Reliafund.
The RequestReturns web service accepts a single string parameter named “sxml”. This parameter
consists of a XML message consisting of multiple tags:
Tag Description
<UserName> Required. User name assigned in the payment server.
<Password> Required. Password for the user name assigned in the payment server.
<Service>
This indicates the amount of return information to report on:
ALL – Reports ALL returns in the ReliaFund system.
FILTER – Selectively filter the return information based on the
remaining XML tags
The remaining tags are optional and only required when <Service> = FILTER
<StartDate>
<EndDate> The date range the return was processed by Reliafund.
<StartSettleDate>
<EndSettleDate> The date range the return was settled by ReliaFund.
<StartReturnID>
<EndReturnID The ReliaFund Return ID range.
<EndReturnID> This is the unique ID Reliafund assigns to the return.
<StartRFID>
<EndRFID>
The RFID range of the original transaction (same as RFID in the
ProcessCheckResponse).
<Amount> Amount of the returned transaction
<RoutingNumber> The routing number of the returned transaction
<AccountNumber> The account number of the returned transaction.
<CheckNumber> The check number of the returned transaction.
Merchant Interface Specification
Proprietary & Confidential Page 32
<UserData1>
Optional user data fields that tie to the AUX_1 – AUX_10 fields from
the ProcessCheck web service to match with the returned transaction
<UserData2>
<UserData3>
<UserData4>
<UserData5>
<UserData6>
<UserData7>
<UserData8>
<UserData9>
Sample RequestReturns XML message format
<RequestReturns>
<UserName>demo</UserName>
<Password>demo</Password>
<Service>FILTER</Service>
<StartDate></StartDate>
<EndDate></EndDate>
<StartSettleDate></StartSettleDate>
<EndSettleDate></EndSettleDate>
<StartReturnID>62</StartReturnID>
<EndReturnID>63</EndReturnID>
<StartRFID></StartRFID>
<EndRFID></EndRFID>
<Amount></Amount>
<RoutingNumber></RoutingNumber>
<AccountNumber></AccountNumber>
<CheckNumber></CheckNumber>
<UserData1></UserData1>
<UserData2></UserData2>
<UserData3></UserData3>
<UserData4></UserData4>
<UserData5></UserData5>
<UserData6></UserData6>
<UserData7></UserData7>
<UserData8></UserData8>
<UserData9></UserData9>
</RequestReturns>
Merchant Interface Specification
Proprietary & Confidential Page 33
RequestReturns Response
The RequestReturns web service returns a single string containing a complex XML message containing
information for each return that met the request criteria.
The format of this XML message is:
<RequestReturnsResponse>
...header tags...
<return>
...return information...
</return>
<return>
...return information...
</return>
...
</RequestReturnsResponse>
The header includes the following tags:
Field Description
<RecordCount> The number of items returned by the request.
The following tags will be provided for each return:
Field Description
<ReturnID> This is the unique ID Reliafund assigns to the return.
<RoutingNumber> The routing number of the transaction.
<AccountNumber> The account number of the transaction.
<CheckNumber> The transaction check number.
<Amount> The amount of the transaction.
<ReturnDate> The date the transaction was returned.
<SettlementDate> The settlement date for the return.
<ReasonCode> The reason code for the return.
<RFID> This is the reference to the original transaction processed by Reliafund and is the same
as RFID in the ProcessCheckResponse.
>Addenda> The 10 character alpha numeric description of the transaction.
<UserData1> User data field from the returned transaction.
<UserData2> User data field from the returned transaction.
<UserData3> User data field from the returned transaction.
Merchant Interface Specification
Proprietary & Confidential Page 34
<UserData4> User data field from the returned transaction.
<UserData5> User data field from the returned transaction.
<UserData6> User data field from the returned transaction.
<UserData7> User data field from the returned transaction.
<UserData8> User data field from the returned transaction.
<UserData9> User data field from the returned transaction.
Sample RequestReturnsResponse XML message format
<RequestReturnsResponse>
<RecordCount>2</RecordCount>
<return>
<ReturnID>62</ReturnID>
<RFID>12</RFID>
<ReturnDate>2/15/2006 12:00:00 AM</ReturnDate>
<SettlementDate>2/15/2006 12:00:00 AM</SettlementDate>
<ReasonCode>R01</ReasonCode>
<RoutingNumber>123456780</RoutingNumber>
<AccountNumber>664753354</AccountNumber>
<CheckNumber>95642</CheckNumber>
<Amount>$134.00</Amount>
<UserData1 />
<UserData2 />
<UserData3 />
<UserData4 />
<UserData5 />
<UserData6 />
<UserData7 />
<UserData8 />
<UserData9 />
<Addenda>799R01075900576999936 07188889 072000918063130</Addenda>
</return>
<return>
<ReturnID>63/ReturnID>
<RFID>9</RFID>
<ReturnDate>2/15/2006 12:00:00 AM</ReturnDate>
<SettlementDate>2/15/2006 12:00:00 AM</SettlementDate>
<ReasonCode>R01</ReasonCode>
<RoutingNumber>123456780</RoutingNumber>
<AccountNumber>35134752354</AccountNumber>
<CheckNumber>16325</CheckNumber>
<Amount>$24.00</Amount>
<UserData1 />
<UserData2 />
<UserData3 />
<UserData4 />
<UserData5 />
<UserData6 />
<UserData7 />
<UserData8 />
<UserData9 />
<Addenda>799R02075900576999936 07188889 072000918063130</Addenda>
Merchant Interface Specification
Proprietary & Confidential Page 35
</Return>
</RequestReturnsResponse>
RequestReturnsResponse – ERROR
If an error occurs and the RequestReturns web service is unable to process the incoming XML message
from the merchant, it will return a single string parameter containing an error response formatted into an
XML message in the following format:
<RequestReturnsResponse>
<ErrorType>ERR</ErrorType>
<ErrorMessage>Error Message</ErrorMessage>
</RequestReturnsResponse>
The following table lists some possible errors that can be returned by RequestReturns:
ResultCode ResultMessage
ERR Invalid user name or password.
ERR User name and/or password were not correct. Please
correct the login credentials and try again.
ERR Service is not valid.
Merchant Interface Specification
Proprietary & Confidential Page 36
RequestTrxInfo
The RequestTrxInfo Service is used to request information for any transactions that have been submitted
to Reliafund for a user’s merchants and/or locations.
The RequestTrxInfo web service accepts a single string parameter named “sxml”. This parameter
consists of a XML message consisting of multiple tags:
Tag Description
<UserName> Required. User name assigned in the payment server.
<Password> Required. Password for the user name assigned in the payment server.
The remaining tags are optional and set filters on what transactions are returned
<RFID> Only include the transaction with this ReliaFund processing queue ID
<Amount> Only include transactions with this dollar amount
<StartDate>
<EndDate> Only include transactions performed within this date range
<StartProcessedDate>
<EndProcessedDate>
Only include transactions processed by ReliaFund within this date
range
<StartEffectiveDate>
<EndEffectiveDate>
Only include transactions posted by the financial institution within this
date range
<StartSettleDate>
<EndSettleDate>
Only include transactions settled to the merchant’s account within this
date range
<StartReturnDate>
<EndReturnDate> Only include transactions that were returned within this date range
<StandardEntryCode> Only include transactions with this SEC
<RoutingNumber> Only include transactions with this routing number
<AccountNumber> Only include transactions with this account number
<CheckNumber> Only include transactions with this check number
<ReturnReasonCode> Only include transactions that have been returned with this ACH return
reason code (R01 – R89)
<ProcessedStatus>
Only include transactions with this ReliaFund processing status code.
Valid values are (case-sensitive): “Preliminary”, “Pending Funding”,
“Approved”, “Processed”, “Complete”, “Returned – Post Settlement”,
and “Resolved – Post Settlement”
<ProcessedState>
Only include transactions with this ReliaFund processing state code.
Valid values are (case-sensitive): “Preliminary”, “Open”, “Complete”,
“Suspended”, “Failed”, and “Void”
<SettlementID> Only include transactions that are a part of this ReliaFund Settlement
ID
Merchant Interface Specification
Proprietary & Confidential Page 37
<ReturnID> Only include the transactions with this return ID
<ExcludeVoide> Pass a value of “True” to exclude voided transactions
Sample RequestTrxInfo XML message format
<RequestTrxInfo>
<UserName>demo</UserName>
<Password>demo</Password>
<StartDate>2011-04-01</StartDate>
<EndDate>2011-04-30</EndDate>
<RoutingNumber>123456780</RoutingNumber>
<ProcessedStatus>Complete</ProcessedStatus>
</RequestTrxInfo>
Merchant Interface Specification
Proprietary & Confidential Page 38
RequestTrxInfo Response
The RequestTrxInfo web service returns a single string containing a complex XML message containing
information for each transaction that met the request criteria.
The format of this XML message is:
<RequestTrxInfoResponse>
...header tags...
<transaction>
...return information...
</transaction>
<transaction>
...return information...
</transaction>
...
</RequestTrxInfoResponse>
The header includes the following tags:
Field Description
<RecordCount> The number of items returned by the request.
The following tags will be provided for each transaction:
Field Description
<RFID> The ReliaFund processing queue ID assigned to the transaction
<RoutingNumber> The routing number of the transaction with all but the last 4 digits masked out
<AccountNumber> The account number of the transaction with all but the last 4 digits masked out
<CheckNumber> The transaction check number.
<Amount> The amount of the transaction.
<TransactionDate> The date the transaction was performed
<ProcessedDate> The date the transaction was processed by ReliaFund
<EffectiveDate> The date the transaction was posted by the financial institution
<SettlementDate> The date the transaction was settled to the merchant account
<ReturnDate> The date the transaction was returned
<StandardEntryCode> The SEC for the transaction
<SettlementID> The ReliaFund settlement ID that the transaction is part of
<ReturnID> This is the unique ID Reliafund assigns to the return
<AuthCode> The authorization code of the transaction, typically either “00” or “ERR”
Merchant Interface Specification
Proprietary & Confidential Page 39
<AuthText> Additional descriptive information relating to <AuthCode>
<ReturnReasonCode> The ACH return reason code (R01 – R89) if the transaction was returned
<ProcessQType> The type of transaction. Values include: “ACH-Debit”, “ACH-Credit”, ACH-Debit
Prenote”, “Check 21”, “Wire/Other”, “Fees”, and “ACH-Credit Prenote”
<ProcessedStatus>
The ReliaFund processing status code for the transaction. Values
include: “Preliminary”, “Pending Funding”, “Approved”, “Processed”,
“Complete”, “Returned – Post Settlement”, and “Resolved – Post
Settlement”
<ProcessedState>
The ReliaFund processing state code for the transaction. Values include:
“Preliminary”, “Open”, “Complete”, “Suspended”, “Failed”, and
“Void”
Sample RequestTrxInfoResponse XML message format
<RequestTrxInfoResponse>
<RecordCount>2</RecordCount>
<transaction>
<RFID>1099723</RFID>
<RoutingNumber>*****6780</RoutingNumber>
<AccountNumber>***********3354</AccountNumber>
<CheckNumber>95642</CheckNumber>
<Amount>$134.00</Amount>
<TransactionDate>04/02/2011 02:52:03 PM</TransactionDate>
<ProcessedDate>04/02/2011 03:02:00 PM</ProcessedDate>
<EffectiveDate>04/04/2011 12:00:00 AM</EffectiveDate>
<SettlementDate>04/09/2011 12:00:00 AM</SettlementDate>
<ReturnDate></ReturnDate>
<StandardEntryCode>POP</StandardEntryCode>
<SettlementRFID>1120700</SettlementRFID>
<ReturnID></ReturnID>
<AuthCode>00</AuthCode>
<AuthText>Approval</AuthText>
<ReturnReasonCode></ReturnReasonCode>
<ProcessQType>ACH-Debit</ProcessQType>
<ProcessedStatus>Complete</ProcessedStatus>
<ProcessedState>Complete</ProcessedState>
</transaction>
<transaction>
<RFID>1099756</RFID>
<RoutingNumber>*****9915</RoutingNumber>
<AccountNumber>***********0997</AccountNumber>
<CheckNumber>01987</CheckNumber>
<Amount>$65.00</Amount>
<TransactionDate>04/15/2011 09:30:19 AM</TransactionDate>
<ProcessedDate>04/15/2011 02:27:00 PM</ProcessedDate>
<EffectiveDate>04/17/2011 12:00:00 AM</EffectiveDate>
<SettlementDate>04/19/2011 12:00:00 AM</SettlementDate>
<ReturnDate></ReturnDate>
<StandardEntryCode>POP</StandardEntryCode>
<SettlementRFID>1230505</SettlementRFID>
<ReturnID></ReturnID>
<AuthCode>00</AuthCode>
Merchant Interface Specification
Proprietary & Confidential Page 40
<AuthText>Approval</AuthText>
<ReturnReasonCode></ReturnReasonCode>
<ProcessQType>ACH-Debit</ProcessQType>
<ProcessedStatus>Complete</ProcessedStatus>
<ProcessedState>Complete</ProcessedState>
</transaction>
</RequestTrxInfoResponse>
RequestTrxInfoResponse – ERROR
If an error occurs and the RequestTrxInfo web service is unable to process the incoming XML message
from the merchant, it will return a single string parameter containing an error response formatted into an
XML message in the following format:
<RequestTrxInfoResponse>
<ErrorType>ERR</ErrorType>
<ErrorMessage>Error Message</ErrorMessage>
</RequestTrxInfoResponse>
Merchant Interface Specification
Proprietary & Confidential Page 41
ReliaFunctions
Overview
ReliaFunctions are a collection of XML web services intended for the exclusive use of ReliaFund
business partners. These services primarily provide utilities that assist partners in validating bank
routing numbers and credit card numbers, interpretation of MICR lines in personal or business checks as
well as to provide tools that permit software publishers and other similar service providers with the
capability of integrating their subscriber/user applications with ReliaFund’s ACH payment processing
services.
Some of these services are available to anyone without setup, while other services require that a master
user account be set up for the publisher as well as pre-populating certain support tables required to
automate the application process.
Once and authorized publishers collects the pertinent information from their subscriber(s) they can use
these services to submit their application to ReliaFund and track the process of accepting, rejecting or
managing the application.
The following is a list of all currently available ReliaFunctions along with a brief description of their
usage. While this document is intended to reflect as accurately as possible the actual published XML
web services, real time access to the web services will expose the most current XML Schemas and
developers are encouraged to refer to:
http://payments.reliafund.com:8081/ReliaFunctions/ReliaFunctions.asmx for the most current
information and updates.
ABAChecksum
ABAChecksum tests the ABA number for compliance with NACHA rules. It does not confirm that the
ABA number is actually representative of a particular financial institution but only that it complies with
the NACHA checksum rules.
SubscriberApplicationAdd
SubscriberApplicationAdd adds a subscriber application to the database. Successful transaction will
return a string containing either a success notification or verbose explanations as to the nature of the
unsuccessful submission.
Field Description
PublisherID Identification of the Software Publisher requesting the
merchant subscription. This ID is furnished to you by
Reliafund.
PublisherPassword The software publisher’s password. . This password is
furnished to you by Reliafund.
SubscriberID The SubscriberID is complex ID assigned by the Publisher
SubscriberPassword The SubscriberPassword is a password to be assigned to the
new subscribers account and is created and assigned by the
publisher.
Merchant Interface Specification
Proprietary & Confidential Page 42
BusinessName Then name of the merchant being added to the system
LastName The merchant contacts last name.
FirstName The merchant contacts first name.
Address1 The merchant’s address line 1
Address2 The merchant’s address line 2
City The merchants city
State The new merchant’s state.
ZIP The new merchant’s postal code.
Phone The new merchant’s telephone number.
Fax The new merchant’s fax number.
Email The new merchant’s contact email.
TaxID The new merchant’s TaxID
LicenseNo The new merchants Business License number.
ProgramSponsorDate (Optional) The ProgramSponsorDate is a date field used by
the publisher to indicate the date the subscriber applied for
or renewed the payment service.
BusinessTypeID The business type.
Use the list return by ApplicationBusinessTypeList in
ReliaFunctions for available valid business types.
ProgramSponsorID ProgramSponsorID is a field used to indicate the sponsor the
payment program. If no sponsor programs are used a default
is 0 (Zero) is used for no Program Sponsor.
BankAccountTypeCode The Deposit account type.
Use SubscriberApplicationBankAccountTypeList in
ReliaFunctions for available valid Bank Account Types.
SettlementABA Deposit Account Routing Number
SettlementAccount Deposit Account Number
SubscriberApplicationBankAccountTypeList
SubscriberApplicationBankAccountTypeList provides a list of valid bank account type codes and
corresponding descriptions for use in populating the publisher’s application forms. The
SubscriberApplicationAdd and SubscriberApplicationChange services require numeric values to
represent these selections.
Code Name Description
0 Checking - Business Checking - Business
1 Checking - Personal Checking - Personal
2 Savings - Business Savings - Business
3 Savings - Personal Savings - Personal
Merchant Interface Specification
Proprietary & Confidential Page 43
SubscriberApplicationBusinessTypeListing
SubscriberApplicationBusinessTypeListing provides a list of valid business type codes and
corresponding descriptions for use in populating the publisher’s application forms. The
SubscriberApplicationAdd and SubscriberApplicationChange services require numeric values to
represent these selections.
Code Name Description
0 Sole Proprietorship Sole Proprietorship
1 Partnership Partnership
2 Corporation Corporation
3 LLC LLC
SubscriberApplicationChange
SubscriberApplicationChange is used to update a subscriber application in the database.
SubscriberApplicationDelete
SubscriberApplicationDelete is used to remove a subscriber application from the database.
SubscriberApplicationList
SubscriberApplicationList returns dataset of subscriptions applications.
SubscriberApplicationMessages
SubscriberApplicationMessages returns messages related to a Subscriber application for origination
processing.
SubscriberApplicationProgramSponsorList
SubscriberApplicationProgramSponsorList provides a list of valid program sponsor codes and
corresponding descriptions for use in populating the publisher’s application forms. Program sponsor
codes are enabled as a secondary validation method to expedite the process of activating subscriptions.
There specific usage will be determined by the agreement between ReliaFund and the publisher. The
SubscriberApplicationAdd and SubscriberApplicationChange services require numeric values to
represent these selections.
ProgramSponsorPublisherID Code Name Description
Xxxxx-xxxxxx-xxxxxxxxx1 0 None No sponsorship
Xxxxx-xxxxxx-xxxxxxxxx2 1 Test Program One Test Program One
Xxxxx-xxxxxx-xxxxxxxxx3 2 Another Test Program Another Test Program
Merchant Interface Specification
Proprietary & Confidential Page 44
SubscriberApplicationStatus
SubscribeApplicationStatus returns the status of a subscriber application for origination processing.
SubscriberApplicationStatusCodeListing
SubscriberApplicationStatusCodeListing provides a list of valid application status codes and
corresponding descriptions for use in populating the publisher’s application forms. The
SubscriberApplicationAdd and SubscriberApplicationChange services require numeric values to
represent these selections.
Code Name Description
0 Submitted Submitted
1 In Process In Process
2 Declined Declined
3 Approved Approved
4 Active Active
ValidateAMEXCard
ValidateMasterCard
ValidateVisaCard
These functions accept credit card numbers and determine if they comply with the corresponding issuers
checksum policy and return a string of ‘True’ for valid numbers or ‘False’ for invalid numbers. Please
Note: This function does not determine if the card number is representative of a valid issued account
simply that the number complies or does not comply with the algorithm for determining valid card
numbers.
Getting Started with Subscriptions
In order for ReliaFund to authorize a software publisher access to the ReliaFunctions Web Services, they
must supply ReliaFund with a list of Subscription Program Sponsors. Once these have been entered into
the subscription system by ReliaFund the Publisher will be issued a UserID and Password.
Subscription Program Sponsors
A program sponsor list must contain at least one entry. As determined by the agreement between
ReliaFund and the publisher, more than one sponsor may be required. In the event that ReliaFund
determines that there will be no requirement for a sponsor, the only entry in the list will be none and
every application will require that the appropriate field be populated with the corresponding number.
Merchant Interface Specification
Proprietary & Confidential Page 45
UserID and Password
UserIDs and Passwords are lengthy and somewhat complex and are not intended to be used for manual
entry but rather to be limited to automated interfaces to the ReliaFunctions web services.
Authorized Publishers
General Queries
Developers should initially query the following services intended to provide information for dropdown
lists or other data validation purposes.
SubscriberApplicationBusinessTypeListing
SubscriberApplicationBankAccountTypeList
SubscriberApplicationProgramSponsorList
SubscriberApplicationStatusCodeListing
Of these functions, the only one that requires UserID is SubscriberApplicationProgramSponsorList
because these are the only results that are unique to a publisher.
Test submission and updating of applications
Developers should submit test applications, test updating their content and check their status and
messages by using the following functions:
SubscriberApplicationAdd
SubscriberApplicationChange
SubscriberApplicationMessages
SubscriberApplicationStatus
SubscriberApplicationList
Once an application is added all of these services are immediately available. Actual authorization is an
administrative function of ReliaFund so nothing will automatically be updated unless testing is being
coordinated with ReliaFund’s Operations staff at (763) 226-2003.