Skip to main content

Overview

About JHA SmartPay PlatformTM. Integrated Payments Platform that Supports Multiple Payment Channels.​

Owning the dynamic payments channel is getting more difficult with new competitors, new payment alternatives, and new end user expectations. But when you choose the JHA SmartPay Platform, you gain fully integrated solutions that support virtually every payment channel and the entire lifecycle of virtually every payment type. These industry-leading solutions can be implemented as a holistic payments ecosystem or as standalone solutions. And additional solutions can be easily added to support your evolving payments strategy and emerging payment channels. These solutions include.

  • JHA SmartPay Remote Deposit CompleteTM (RDC) – High-volume remote deposit capture with proofing and balancing services
  • JHA SmartPay Remote Deposit NowTM (RDN) – High-volume remote deposit capture with business-managed proofing and balancing
  • JHA SmartPay mRDCTM (Mobile Remote Deposit Complete) – Commercial mobile remote deposit capture solution built exclusively for businesses
  • JHA SmartPay ExpressTM – Payments portal for online payments and donations
  • JHA SmartPay Biller DirectTM – Electronic bill/invoice presentment and payment solution for billers
  • JHA SmartPay CardTM – Cost-effective card transaction processing for small and large merchants
  • JHA SmartPay ACHTM – Sophisticated bulk file or individual ACH transaction processing
  • JHA SmartPay ManagerTM – Intelligent administrative portal

About the JHA Transaction Processing Web Service​

The Transaction Processing Web Service exposes a set of application program interfaces (APIs) that enables a way to send transaction operations to the JHA SmartPay Platform from within your application. Enterprise Payment Solutions (EPS) robust APIs can be configured and deployed to offer highly scalable payment solutions for near-term needs, with the flexibility to quickly and seamlessly add payment options to support evolving business strategies and market demands. Following are the features that are available through the Transaction Processing API’s.

List of features

  • Process ACH Ability to process credit, debit and same day ACH transactions into a NACHA file.
  • Process Check21 Ability to process check images with MICR lines into an X9 file.
  • Process Credit Card Ability to process credit or debit transactions to credit cards for supported card processors.
  • Associate Customer Ability to add customer information to a transaction for reporting.
  • Custom Field Data Allows each transaction to have up to three fields of customized information for reporting.
  • Batch Management Allows for managing batches of transactions to control grouping of settlements and processing times.
  • Custom Description Allows a custom description to be associated with each transaction.
  • Void and Refund Transactions Offers the ability to refund card and ACH transactions, and void transactions prior to processing.
  • Get Transaction Data Ability to retrieve status, details and images of a single transaction.

Required, System Required/User Optional and Optional Data Elements​

Required Data Elements​

There are some elements contained within TransactionProcessing that are required and the applicable data will be provided to you by ProfitStars EPS when your merchant account has been set up. These required elements are shown below.

  • storeId - A unique user ID systematically generated by EPS upon installing a web service user. The storeId can be unique to each individual merchant, or a master storeId can be assigned at the reseller/owner level.
  • storeKey – A unique password systematically generated by EPS upon installing a web service user. The password corresponds with the storeId above.
  • entityId - The entityId is a unique identifier that is systematically generated when the merchant is installed on the EPS system. It is also referred to as the Merchant ID or MID.
  • locationId - The locationId is a unique identifier for each location (account) set up under a user. Users that process transactions for multiple accounts, or use the same account for multiple purposes (i.e. building fund, donations, dues), will be assigned individual location IDs for each.
    note

    Only those fields required by the EPS system will de denoted by a Y in the Required column.

Optional Data Elements​

For some optional elements, if the element is included in the request, then a value must be provided by the user. This means that the element can be null but cannot be empty. These elements are listed below.

  • TaxAmount - The information supplied in this element is stored but Not used at this time with any other operation. This element will accept a value of 0 or 0.00 if included in the request.
  • ShippingAmount – The information supplied in this element is stored but Not used at this time with any other operation. This element will accept a value of 0 or 0.00 if included in the request.
  • terminalNumber - The default value for terminalNumber is ‘__WebService’. The default value will be assumed if the element is null. If a value is provided and not accurate, an error will occur.
  • notificationMethod/NotificationMethod - This element represents the method by which a merchant’s customer will be notified of an ACH or Credit Card transaction. Valid values are: Merchant_Notify (default), Merchant_Recording, Postcard or Email. If this element is not included in the request, then the default value of Merchant_Notify will be assumed. If a notification via ‘Email’ is requested for ACH or Credit Card transactions, the following fields and elements will need to be set up and included in the requests as follows:
      1. The ‘Email’ notification option will need to be set up and enabled for the Merchant Default or specific Location, (this can be requested of the EPS file maintenance group).
      1. An email address must be included in any Authorize Transaction methods.
      1. The Notificationmethod element must contain the value ‘Email’ in the web service request.
  • paymentOrigin – This element identifies by what method the transaction was originated. If this element is not included in the request, then the default value of ‘Internet’ is assumed.
  • IsCompany – This element identifies whether a customer is an individual or business. Acceptable values are 1 (True) or 0 (False). The default value of ‘Individual’ will be used if null.
  • faceFeeType – This element designates what type of fee is being charged. The default value of ‘Face’ will be used if set to ‘__None’ or null.
  • SettlementType – This element identifies the transaction type. i.e. ACH, Check_Image etc. If null, the default value of ‘ACH’ will be assumed.
  • EffectiveDate – This element identifies the date and time the transaction will be, or was, processed. If null, the current date and time will be assumed. If a date is provided without a specific time, then the exact time the transaction is processed will be applied.
note

The Time is not required to be included in the request for this element.

  • OperationType - This element identifies the transaction as either a debit or credit (including Same Day ACH debits or credits). If null, the default value of ‘Sale’ will be assumed.
  • captureAmount - This element represents the amount of the authorized transaction to be validated. If null, the original transaction amount will be assumed and accepted.
  • includeImages - This element designates whether images of the document will be included in the request. If included, valid values are: 0 = False; 1 = True
  • PresentmentNumber - The value in this element indicates which re-presentment of the item this is. Acceptable values are: ‘0’ (Original presentment) (Not RCK); ‘1’ (First re-presentment); or ‘2’ (Second re-presentment).
    • For RCK Payment Origins of Bounced_Check, or Represented_Check, this value MUST be ‘1’ or ‘2’. No other values will be accepted. o For ARC, BOC, POP (POS), PPD or TEL transactions, a value of ‘0’ is acceptable, however it will be considered as an original transaction and be ignored as a re-presented item.
    • Presentment numbers > ‘2’ will result in an error.
note

For non-re-presented transactions the recommendation is to remove this element from the request.

  • ownerApplication – The ownerApplication element indicates what application was used to create the transaction. If null, the default value “Web_Service” will be assumed.
  • depositSlipId - The information supplied in this request is dependent on whether the field is Optional, Required, None or a specific value (Static) for the location. It cannot be null or blank. If ‘None’ or a ‘Static’ value is required, ‘0’ must be entered. Any other value will be ignored. If ‘Required’, a value > 0 must be supplied. If ‘Optional’, any value >= ‘0’ will be accepted.

PaymentOrigin Element Relationships​

The PaymentOrigin value within each AuthorizeTransactionWithCustomer or Authorize Transaction request affects which additional optional elements will be required. Below, is an explanation of how the PaymentOrigin element works in conjunction with some of the other optional elements.

  1. CheckMICRLine
    • Required only when PaymentOrigin is Mailed_In, Drop_Box, Back_Office or Retail__POS, this element is used to determine the Routing/Transit, Account and Check Serial numbers of the transaction in the request.
    • If this element is included in the request the CheckNumber, RoutingNumber and AccountNumber elements are ignored and should not be included.
    • The check serial number is required for all ACH transactions. If the check number is not provided Mailed_In, Drop_Box and Back_Office transactions will originate as IRD/Check21 transactions.
    • Retail__POS requires the check number along with the CheckFrontImageBytes_TiffG4 element. If a check number is not available, the message “Account_Not_ACHable” is received and the transaction will not be successful.
  2. CheckMICRSymbolSet
    • Required when CheckMICRLine is included in the request.
  3. RoutingNumber
    • Required for ACH transactions when PaymentOrigin = Internet, Bounced_Check, Represented_Check, Telephone_IVR, Telephone_Operator, Signature_Faxed, Signature_Original or Corporate_Trade_Exchange only.
    • This element should be removed if this is a credit card account or CheckMICRLine is included in the request.
  4. AccountNumber
    • Required for ACH transactions when PaymentOrigin = Internet, Bounced_Check, Represented_Check, Telephone_IVR, Telephone_Operator, Signature_Faxed, Signature_Original or Corporate_Trade_Exchange only.
    • Required if CheckMICRLine is not included in the request for ACH transactions or SwipeTrack2 is not included for Credit Card transactions.
    • This element should be removed if this is a credit card account.
  5. CheckNumber
    • when PaymentOrigin = Bounced_Check or Represented_Check.
    • This element should be removed if this is a credit card account or CheckMICRLine is included in the request.
  6. CheckFrontImageBytes_TiffG4
    • Required when PaymentOrigin is Mailed_In, Drop_Box, Back_Office, Bounced_Check, Represented_Check or Retail__POS.
  7. PresentmentNumber
    • Required when PaymentOrigin is Bounced_Check or Represented_Check.
    • Optional for ARC (Mailed_In), BOC (Back_Office), POP (Retail__POS), PPD (Signature_Original, Signature_Faxed), and TEL (Telephone_IVR, Telephone_Operator) re-presented transactions.
    • Must be a ‘1’ or ‘2’ for all ‘Face and NSF_Fee (not RCK) re-presented transactions.
    • If the item is not a re-presentment transaction do not include this element in the request.

Special Requirements​

  • OperationType - Per Nacha rules, same-day ACH credit (SDCredit) and debit (SDSale) transactions cannot exceed $1,000,000 (1 Million).

This document will make every effort to identify each of these element types within a method.

Data Returned Limitation​

Requests for data that exceeds 100k records will return a TR01 error response as displayed below.

“Server was unable to process request. ---> An exception of type System.ApplicationException was thrown. The message was TR01 - The amount of data you requested exceeds system limitations and cannot be processed. Reduce the input range and submit your request again.”

System Requirements​

Secure Sockets Layer (SSL) Implementation Required​

Requests must be originated using HTTPS protocol. This requires requesting servers/users to use the Secure Socket Layer (SSL) for encrypted communication.

Image Tiff Requirements​

Check21 images submitted through Web Services by verifying the DPI reported on the individual check image to determine if it is within the accepted industry standard of 200 or 240 DPI (with tag ids 282 and 283). If the DPI is reported outside the range of valid values, ProfitStars EPS will examine the image width and length to determine whether the DPI is set in error and accept the image if this seems to be the case. EPS PS calculations indicate the DPI is either 200 or 240, we will allow the transaction to pass this validation. If the EPS PS calculations indicate the DPI is outside this range, it will be rejected with the “invalid check images” error message.

In addition, the following image rules should be followed.

  • Little Endian format
  • G4 Compression
  • Single Strip – RowsPerStrip should be equal to the ImageLength