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 Payment Vault Web Service​

The Payment Vault 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 Payment Vault API’s.

List of features​

  • Process ACH - Ability to process credit, debit and same day ACH transactions into a NACHA file.
  • Process Credit Card - Ability to process credit or debit transactions to credit cards for supported card processors.
  • Batch Management - Allows for managing batches of transactions to control grouping of settlements and processing times.
  • Setup and Manage Recurring Schedules - Ability to setup an ACH and credit card payment schedules that leverages the SmartPay recurring engine to process based on frequency, number of payments, and start date.
  • Custom Description - Allows a custom description to be associated with each transaction.
  • Custom Field Data - Allows each transaction to have up to three fields of customized information for reporting.
  • Register and manage accounts - Ability to create and manage accounts that are stored in SmartPay with a tokenized reference value. The reference value is used in subsequent transactions.
  • Register and manage Customers - Ability to create and manage customers, individual or business types, that are stored in SmartPay with a tokenized reference value. The reference value is used in subsequent transactions.
  • 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 data elements contained within PaymentVault are required and the applicable data will be provided to you by 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.
  • BinarySecurityToken - This is an access token that is generated via a request to an authentication endpoint. This access token will need to be submitted via the SecurityHeader portion of the header in each request. See the Authentication Guide for more info.
note

Required fields will be identified by a “Y" in the required column

System Required/User Optional Data Elements​

Other elements are required but do not necessarily have to be supplied by the user. When registering an account or customer, creating a transaction or batch, or setting up a recurring payment. Requested items that are left blank during set up will be assigned a system generated value. It is highly recommended however, that users assign their own unique values to these elements to facilitate the retrieval, updating or disabling of a batch, transaction, account or customer. The elements below are unique identifiers that reference a specific account, customer, transaction or batch.

  • recurrRefId/recurringReferenceID/RecurringReferenceID - The Reference ID for Recurring Payments is used to identify a recurring payment that has been setup for a customer.
  • customerNumber/CustomerNumber - The Customer Number is a unique identifier for each customer that is registered.
  • accountRefId/accountReferenceId/AccountReferenceID - The Account Reference Id is a unique identifier for a specific account that is registered for a customer.
  • transactionNumber/TransactionNumber - The Transaction Number is a unique identifier of each transaction in the EPS system. A value will be assigned if one is not supplied by the user. Recurring Payment transactions will be in the format of: InvoiceNumber (if supplied): PaymentsToDate: System generated recurring payment ID.

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);
    2. An email address must be included in any AuthorizeTransaction methods;
    3. 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.
  • Approved - This element is no longer used, but if included in the request, the acceptable values are 1 (True) or 0 (False). We suggest not including this field.
  • UsedForMatching - This element is no longer used, but if included in the request, the acceptable values are 1 (True) or 0 (False). We suggest not including this field.
  • faceFeeType - This element designates what type of fee is being charged. The default value of Face will be used if null or set to “__None”.
  • Frequency - This element identifies how often to take a recurring payment. The default value of Once_a_Month will be used, if null.
  • NextPaymentDate - This element represents the next date on which to take a recurring payment. If null, the EPS system will calculate the value for this element.
  • ownerApplication - The ownerApplication element indicates what application was used to create the transaction. If null, the default value “Web_Service” will be assumed.
  • storedCredential - This element defines how a Credential on File (Card on File) transaction is being used. Valid values are Customer (used when the customer initiates an unscheduled transaction using a stored account), Unscheduled (used when a merchant initiates an unscheduled transaction using a stored account), and Recurring (used when a scheduled recurring transaction uses a stored account). If null, the default value of _None is used.

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

Credit Card Processing - Credential on File (Card on File)​

Recent payment network (Visa, MasterCard, Discover, American Express) changes to how payment cards are stored, and their use defined during authorization will impact all customers who store credit card accounts and process authorizations with those stored credit card accounts.

EPS will transition availability for Credential on File with supported credit card processors as it becomes available. During the transition phase, the storage of a card account to the Payment Vault will support multiple workflow scenarios dependant upon Credential on File support. Integrators should not mix workflows, and once a supported processor becomes available the new workflow should be consumed. Only the impacted Payment Vault Web Service methods are discussed in this section. These workflows are defined below.

  • Non-Card on File
    • This workflow operates using three Payment Vault Web Service methods.
      • RegisterAccount- EPS will store the credit card account directly and no verification authorization will occur.
      • UpdateAccount - EPS will update the stored credit card account and no verification authorization will occur.
      • SaleFromCardAccount - EPS will not require the integrator define how the authorization is being used.
  • Card on File
    • This workflow operates using three Payment Vault Web Service methods.
      • RegisterCardAccount - EPS will send a verification authorization prior to storing the credit card account. Per payment network rules, if the verification authorization fails, the credit card account cannot be stored. The change with this new method is the requirement of a LocationID. A verification authorization is a transaction that must correctly be associated with a merchant processing account.
      • UpdateCardAccount - EPS will update the stored card account and under certain conditions will send a verification authorization prior to performing the update. If the verification authorization fails, the credit card account cannot be updated. The change with this new method is the requirement of a LocationID. A verification authorization is a transaction that must correctly be associated with a merchant processing account.
      • SaleFromCardAccount - EPS will require the integrator define how the authorization is being used. The modification of this method is a new parameter defining how the stored transaction is being used, i.e. a recurring transaction.

Currently supported processors:

  • BridgePay - First Data North
  • Card Gateway - First Data Terminal Settlement (Nashville)
  • Card Gateway - Global Payments

Data Privacy - ForgetCustomer​

EPS’s Electronic Data Privacy Project (EDPP) ensures that EPS products remain compliant with data privacy regulations like the California Consumer Privacy Act (CCPA). It also draws from provisions in the European Union’s General Data Protection Regulation (GDPR).

Under the CCPA, a customer has the right to know what personal information (PI) a merchant has collected about them and can request that it be deleted.

Resellers and Direct Business Customers must be able to submit a Forget Customer Request through the Payment Vault web service.

For a customer who has been forgotten:

  • Customer Personal Data
    • All previous transactions of a forgotten customer can be retrieved, but the customer’s personal data will be erased from EPS’s system.
    • The forgotten customer cannot be associated with any new transactions going forward.
    • The forgotten customer’s personal data cannot be updated.
  • Customer Accounts
    • The forgotten customer’s account information will be erased.
    • The forgotten customer’s account cannot be associated with any new transactions.
    • The forgotten customer’s accounts cannot be updated.
  • Customers Recurring Payments
    • The forgotten customer’s recurring payments will be disabled.
    • The forgotten customer’s recurring payment for a future date will not be scheduled.
    • The forgotten customer’s recurring payment cannot be updated.
  • Reports
    • Transaction reports will work the same as for regular customers, except that the forgotten customer data will be erased or replaced with Null values.
  • Not Supported: Money Center entity.

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​

The system validates 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, 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. If the ProfitStars EPS calculations indicate the DPI is either 200 or 240, we will allow the transaction to pass this validation. If the calculations indicate that the DPI is outside this range, it will be rejected with the “invalid check images” error message.