reliafund merchant interface specification

Merchant Interface Specification

Revision Date: 2/23/2012 3:37:00 PM

Proprietary & Confidential



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



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



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.



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



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



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>



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>



<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>


<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>


<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



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>




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



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


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




(prenote)

<CheckNum>




<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>



<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>


<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>




<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>



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.


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.



<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>



<ResultMessage>Approved</ResultMessage>

<RFID>343</RFID>



</Transaction>

</Batch>


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>


<ResultMessage>Error Message</ResultMessage>


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.



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:




<TerminalID>







(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



<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">




<ABA>123456780</ABA>




<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:



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:




<RFID> The ReliaFund processing queue ID of the transaction to void

Sample VoidTrx XML message format

<VoidTrx xmlns="http://service.Reliafund.com/Transact">



<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.



Sample VoidTrx Response XML:

<SimpleProcessResult>


<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:




<RFID> The ReliaFund processing queue ID of the transaction to void

<CheckNum>




<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">



<RFID>197204</RFID>


<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).



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.


Frank to do a "PUSH"

(meaning Joe’s account will

PUSH the funds to Frank’s

with a credit transaction).


credit transaction created by

Joe and using Frank's

account info.


settlement debit credit to

Joes account in the normal

way

1. Joe is the merchant and

need to send (PUSH) money

to Frank.


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).


debit transaction created by

Frank and using Joe’s

account info.


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:


<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



<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


should use this field to denote the type of, or reason for, the transaction.

<CheckNun>




<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>


</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:






<RFID> The ReliaFund processing queue ID of the transaction

Sample GetTrxInfo XML message format

<GetTrxInfo xmlns="http://service.Reliafund.com/Transact">



<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>


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


<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



<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>


<ResultMessage>Retrieved</ResultMessage>

<ResultData>

<Amount>30</Amount>



<RFID>197323</RFID>

<AuthCode>00</AuthCode>

<AuthText>Approval</AuthText>

<StandardEntryCode>PPD</StandardEntryCode>

<TransactionType>Credit</TransactionType>

<ABA>*****0019</ABA>

<Account>**1111</Account>


<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.



The GetTrxAuxInfo web service accepts a serialized XML parameter list described below:




<RFID> The ReliaFund processing queue ID of the transaction

Sample GetTrxAuxInfo XML message format

<GetTrxAuxInfo xmlns="http://service.Reliafund.com/Transact">



<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>




further details.


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>



<AUX_7>

<AUX_8>

<AUX_9>

<AUX_10>

Sample GetTrxAuxInfo Response XML:

<AuxProcessResult>



<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:




<TrxCount> The number of RFIDs to return, from 1 to 999



<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">



<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>




further details.


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>



<RFIDList>

<string>197578</string>





</RFIDList>

</ProcessListResult>



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" & _



"&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


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>"


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")





.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


xmlText = "sxml=" & _

"<ProcessCheck>" & _




"<Batch RecordCount='1' BatchTotal='52.08'>" & _

"<Transaction>" & _

"<TransactionID>1</TransactionID>" & _

"<Service>Add</Service>" & _

"<StandardEntryCode>FEE</StandardEntryCode>" & _


"<TranType>0</TranType>" & _



"<ABA>123456780</ABA>" & _

"<Account>123456789012</Account>" & _



"<PayerName>Joe Smith</PayerName>" & _

"</Transaction>" & _

"</Batch>" & _

"</ProcessCheck>"


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))



SOAP 1.1 method using MSXML 3.0 object MSXML2.ServerXMLHTTP



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.


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>" & _





"<Transaction>" & _








"<ABA>123456780</ABA>" & _

"<Account>123456789012</Account>" & _





"</Batch>" & _

"</ProcessCheck>" & _

"</sxml>" & _

"</ProcessCheck>" & _

"</soap:Body>" & _

"</soap:Envelope>"


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")



.NET WebReference to “http://payments.reliafund.com/transact/transact.asmx”


Dim xmlResponseText As String

xmlText = "<ProcessCheck>" & _





"<Transaction>" & _










"<ABA>123456780</ABA>" & _

"<Account>123456789012</Account>" & _





"</Batch>" & _

"</ProcessCheck>"

Dim ReliafundServices As New WebReference.Transact

xmlResponseText = ReliafundServices.ProcessCheck(Convert.ToString(xmlText))

MsgBox(xmlResponseText)



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



<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.



<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>


<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>









</RequestReturns>



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>

...

</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.











Sample RequestReturnsResponse XML message format


<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>


<ReasonCode>R01</ReasonCode>


<AccountNumber>35134752354</AccountNumber>



<UserData1 />

<UserData2 />

<UserData3 />

<UserData4 />

<UserData5 />

<UserData6 />

<UserData7 />

<UserData8 />

<UserData9 />

<Addenda>799R02075900576999936 07188889 072000918063130</Addenda>



</Return>


RequestReturnsResponse – ERROR

If an error occurs and the RequestReturns web service is unable to process the incoming XML message




<ErrorType>ERR</ErrorType>

<ErrorMessage>Error Message</ErrorMessage>


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.



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



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



<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>


<Password>demo</Password>

<StartDate>2011-04-01</StartDate>

<EndDate>2011-04-30</EndDate>


<ProcessedStatus>Complete</ProcessedStatus>

</RequestTrxInfo>



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>


</transaction>

<transaction>


</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”



<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


<RecordCount>2</RecordCount>

<transaction>

<RFID>1099723</RFID>

<RoutingNumber>*****6780</RoutingNumber>

<AccountNumber>***********3354</AccountNumber>



<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>


<ReturnDate></ReturnDate>

<StandardEntryCode>POP</StandardEntryCode>

<SettlementRFID>1120700</SettlementRFID>

<ReturnID></ReturnID>



<ReturnReasonCode></ReturnReasonCode>

<ProcessQType>ACH-Debit</ProcessQType>


<ProcessedState>Complete</ProcessedState>

</transaction>

<transaction>

<RFID>1099756</RFID>

<RoutingNumber>*****9915</RoutingNumber>

<AccountNumber>***********0997</AccountNumber>



<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>


<ReturnDate></ReturnDate>

<StandardEntryCode>POP</StandardEntryCode>

<SettlementRFID>1230505</SettlementRFID>

<ReturnID></ReturnID>





<ReturnReasonCode></ReturnReasonCode>

<ProcessQType>ACH-Debit</ProcessQType>


<ProcessedState>Complete</ProcessedState>

</transaction>


RequestTrxInfoResponse – ERROR

If an error occurs and the RequestTrxInfo web service is unable to process the incoming XML message




<ErrorType>ERR</ErrorType>

<ErrorMessage>Error Message</ErrorMessage>




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.

http://payments.reliafund.com:8081/ReliaFunctions/ReliaFunctions.asmx



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



SubscriberApplicationBusinessTypeListing

SubscriberApplicationBusinessTypeListing provides a list of valid business type codes and





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



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



SubscriberApplicationStatus

SubscribeApplicationStatus returns the status of a subscriber application for origination processing.

SubscriberApplicationStatusCodeListing

SubscriberApplicationStatusCodeListing provides a list of valid application status codes and





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.



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.

reliafund merchant interface specification

Documents