| Environment | Base URL |
|---|---|
| Sandbox | https://secure.epxuap.com |
How To Start
- Contact us for test credentials that can be used to try out the payment API in a test environment.
Once test credentials are provisioned, they can be referenced when logged in by selecting the User profile icon in the top right corner of the screen and selecting Credentials. - Use the API specification or the Postman Collection to build your app against the test environment.
Additional resources to assist with development, including test data, are provided here.
When logged in, you can use the Integration Tracker to view the status of your integration, notes from meetings with Integration Engineers, resources related to your solution, and more by clicking the User profile icon in the top right corner of the screen and selecting Integrations. - Submit a request for certification using our contact form. One of our analysts will begin the review process by validating the data you provided against our internal logs. If any changes are needed, our analysts will work with you until the application is ready to be certified.
- You'll receive a letter of EPX certification with production credentials and can deploy your application for use.
How To Test
Contact us for test credentials that can be used to try out the payment API in a test environment. Once test credentials are provisioned, they can be referenced when logged in by selecting the User profile icon in the top right corner of the screen and selecting Credentials.
HTTPS Request Method
Data is formatted utilizing the key-value pair format and sent via a POST or GET request to the Pay-by-Bank (ACH) API over the standard HTTPS port, 443. Responses are received in XML format.
If using a GET request, the request body is built as one string, which includes both the request URL and the data elements. Below is a sample request to our testing environment:
Note: Each key-value pair is separated by an ampersand (&), and an ‘End of Request’ marker is not required because the last field is simply the end of the request. When submitting a request in this manner, the fields do not need to be in any particular order.
If using a POST request, you do not need to build the combined string. You can use your preferred library to send the request to the Pay-by-Bank (ACH) API, or you can post from an HTML form to your server to submit the data to EPX. See below for an HTML example of this method.
Example HTML Code
HTML
Example XML Response
Request Fields
| Field Name | Description |
|---|---|
CUST_NBR / MERCH_NBR / DBA_NBR / TERMINAL_NBR | These 4 values create your “4-part key” that is provided to you by the integration engineers. The 4-part key will be provided to you in |
TRAN_TYPE | This field relates to the TRAN_TYPEs listed in the EPX Data Dictionary and Transaction Specs - ACH documentation. This field will determine which type of transaction you will process. |
AMOUNT | The amount of the transaction. When processing USD, the value here needs to be in ##.## format, with two decimal places. |
BATCH_ID | The BATCH_ID field contains a unique number created by the operator to identify a batch of transactions. This unique number can be created by any means, but we suggest using the current date in YYYYMMDD format. |
TRAN_NBR | A numeric value, used to identify the transaction. This should be unique for each transaction in a batch. You can just start the first transaction of the day at 1 and increment this number by 1 for each new transaction. |
ACCOUNT_NBR | The bank account number to be acted upon during the transaction. |
ROUTING_NBR | The bank routing number to be acted upon during the transaction. |
FIRST_NAME | First name of the account holder. Required unless STD_ENTRY_CLASS is 'CCD', which stands for Corporate Credit or Debit Entry, in which case RECV_NAME is required. |
LAST_NAME | Last name of the account holder. Required unless STD_ENTRY_CLASS is 'CCD', which stands for Corporate Credit or Debit Entry, in which case RECV_NAME is required. |
ADDRESS / CITY / STATE / ZIP_CODE | These fields are optional. |
STD_ENTRY_CLASS | Optional. If not provided, the SEC code that is set in the merchant profile will be used. |
RECV_NAME | Optional unless STD_ENTRY_CLASS is 'CCD', which stands for Corporate Credit or Debit Entry. |
The HTTPS method creates an individual connection to the Pay-by-Bank (ACH) API for each transaction request, and the connection is closed after the response is received. The key portion of each pair represents the field name from the EPX Data Dictionary, while the value portion represents the merchant’s data that will be the value for that field. In the sample provided, the “CUST_NBR” is a key or EPX field, and “1234” is the value or merchant’s data.
For more information on available fields and transaction types for the Pay-by-Bank (ACH) API, please refer to the EPX Data Dictionary and Transaction Specs - ACH documents.
Fraud Protection
North validates that the payment bank account is open and in good standing before processing ACH payments by validating the bank routing number and account number (note that this does not check the balance or whether an ACH payment will process). If a bank account is closed, does not exist, or is not in good standing, the transaction will be declined at the time of the request.
Making a Sale
A transaction request can be submitted with the CKC2 transaction type for checking accounts, or CKS2 for savings accounts, along with the bank account number and routing number. Please refer to the API specification for more details.
Issuing a Refund
The full or partial amount of the original transaction can be refunded using the CKC3 transaction type for checking accounts, or CKS3 for savings accounts.
Funding
The ACH standard funding timeframe is as follows: If a transaction is submitted on Monday before the settlement cut-off time, the merchant will receive those funds in their bank account on Thursday morning. If the customer’s bank rejects the funding for any reason, such as the account having insufficient funds, the merchant will not be funded. See the Bank Rejects section below for more information.
Reporting
ACH transaction information can be accessed in multiple locations in Payments Hub:
- Payments Hub Dashboard On the Dashboard “Home” screen, the Activity, Transaction Volume, and Payment Method Breakdown summary tiles include ACH transaction information. Hovering over data elements on these tiles provides additional detail about the information in the charts.
- Payments Hub Sales On the “Sales” tab, the Volume chart shows all transactions for the period and the associated data in the table at the bottom. On the “Method” tab, the ACH transaction information is displayed in the chart on the left as “Bank Account” and broken out in the chart on the right as the specific payment method type “Checking Account” or “Savings Account”. The data table at the bottom includes the ACH transaction information including transaction count, gross sales, refunds, voids, and net sales.
- Payments Hub Transactions ACH transactions, along with all transactions, are displayed on the “Transactions” tab. Merchants can easily differentiate between ACH and other transactions looking at the Transaction Type column. Merchants can filter to show only ACH transactions by selecting the “Bank Account Sales” filter on the left. By clicking a transaction row a merchant can open the detailed transaction view where they can see more information about the transaction or take actions like resending the receipt, printing the receipt, voiding the transaction, or refunding the transaction.
- Payments Hub Reports
ACH transactions will display in the Payments Hub reports tab. The report “Brand Summary” shows all activity for ACH and card payment methods by brand (Visa, MasterCard, Checking Account, etc.). This is different from the “Card Brand Summary Report” which only shows card activity. All of the reports on Payments Hub continue to operate the same way and merchants who accept ACH will have that data included in their reports.
ACH Transaction Response Codes
| Code | Display | Description |
|---|---|---|
| 00 | ACCEPTED | ACCEPTED |
| 03 | INVALID MERCHANT | INVALID MERCHANT OR SERVICE PROVIDER |
| 06 | ERROR | ERROR |
| 12 | INVALID TRANS | INVALID TRANSACTION |
| 13 | AMOUNT ERROR | INVALID AMOUNT |
| 14 | INVALID ACCT NBR | INVALID ACCOUNT NUMBER |
| 19 | RE ENTER | RE-ENTER TRANSACTION |
| 21 | NO ACTION TAKEN | NO ACTION TAKEN |
| 25 | UNABLE TO LOCATE | UNABLE TO LOCATE RECORD IN FILE |
| 52 | NO CHECK ACCOUNT | NO CHECKING ACCOUNT |
| 53 | NO SAVE ACCOUNT | NO SAVINGS ACCOUNT |
| 58 | SERV NOT ALLOWED | TRANSACTION NOT ALLOWED AT TERMINAL |
| 61 | DECLINE | ACTIVITY AMOUNT LIMIT EXCEEDED |
| 76 | NO ACTION TAKEN | UNABLE TO LOCATE PREVIOUS MESSAGE (NO MATCH ON RRN) |
| 77 | NO ACTION TAKEN | NO MATCH ON ORIGINAL MESSAGE |
| 78 | INVALID RTN NBR | INVALID ROUTING NUMBER |
| 80 | DATE ERROR | INVALID DATE |
| 96 | SYSTEM ERROR | SYSTEM ERROR |
| E1 | INVALID SEC | INVALID OR UNSUPPORTED SEC |
| E7 | TERMINAL ID ERROR | TERMINAL ID ERROR |
| EA | AUTH TO OLD | AUTH TO OLD |
| EQ | NO NETWORK GATEWAY AVAILABLE | NO NETWORK GATEWAY AVAILABLE |
| ES | DECLINE | Transaction not allowed due to failure of internal validations |
ACH Transaction Rejects
An ACH transaction may be rejected if the transaction cannot be posted (for example, if the account has insufficient funds), or if an entry is disputed. After the ACH transaction is submitted, a 60 day period begins during which the customer can dispute the transaction and the funds for the transaction amount may be removed from the merchant’s account. After 60 days, the funds may not be removed from the merchant’s account.Common reject response codes are listed below.
| Return Code | Reason For Return | Applicable SEC Codes | Deadline For Return |
|---|---|---|---|
| R01 | Insufficient Funds – Available balance is not sufficient to cover the dollar amount of the debit entry | ALL | 24 Hours |
| R02 | Account Closed – A previously open account is no longer open | ALL | 24 Hours |
| R03 | No Account / Unable to Locate – The account number does not correspond to the individual identified in the entry or a valid account | ALL | 24 Hours |
| R04 | Invalid Account Number – The account number fails the check digit validation or may contain an incorrect number of digits | ALL | 24 Hours |
| R05 | Unauthorized Debit to Consumer Account using Corporate SEC Code – A business (corporate) debit entry was transmitted to a member’s consumer account, and the member had not authorized the entry | CCD, CTX | 60 Days – Written statement of unauthorized ACH debit |
| R06 | Returned per ODFI’s Request – The ODFI has requested that the RDFI return the entry | ALL | Not Applicable |
| R07 | Authorization Revoked – Member who previously authorized recurring entry has revoked authorization with the Originator | PPD & Recurring WEB | 60 Days – Written statement of unauthorized ACH debit |
| R08 | Payment Stopped - Member had previously requested a stop payment of a single on recurring entry | ALL | 24 HOURS |
| R09 | Uncollected Funds – Available balance is sufficient, but collected balance is not sufficient to cover the entry | ALL | 24 HOURS |
| R10 | Member advises not authorized, notice not provided, improper source document, or amount of entry not accurately obtained from source document | ARC, POP, PPD, TEL, WEB, BOC | 60 DAYS – Written statement of unauthorized ACH debit |
| R14 | Representative Payee Deceased – Representative payee is deceased or unable to continue in that capacity, beneficiary is not deceased | ALL except CCD & CTX | 24 HOURS |
| R15 | Beneficiary or Account Holder Deceased | ALL except CCD & CTX | 24 HOURS |
| R16 | Account Frozen – Access to account is restricted due to specific action taken by the RDFI or by legal action | ALL | 24 HOURS |
| R20 | Non-Transaction Account – Policies or regulations (such as Regulation D) prohibit or limit activity to the account indicated | ALL | 24 HOURS |
| R29 | Corporate Entry Unauthorized – RDFI has been notified by business account holder that a specific transaction is unauthorized | CCD & CTX | 24 HOURS |
| R31 | Permissible Return Entry – ODFI agrees to accept a return of an unauthorized corporate entry after the 24 hour deadline | CCD & CTX | Not Applicable |
| R37 | Improper Source Document / Source Document Presented for Payment RDFI determines that the document (share draft/check) used for an ARC, BOC or POP entry is not eligible for conversion – or the share draft has already been paid as a normal check posting | ARC, POP, BOC | 24 HOURS |
| R38 | Stop Payment on Source Document – Stop payment has been placed on a check used for an ARC entry | BOC, ARC | 60 DAYS |
| R39 | Improper Source Document / Source Document Presented for Payment RDFI determines that the document (share draft/check) used for an ARC, BOC or POP entry is not eligible for conversion – or the share draft has already been paid as a normal check posting | ARC, POP, BOC | 24 HOURS |
Dishonored Return Entry
| Dishonored Return Code (Submitted by ODFI) | Code Explanation | Possible Action by RDFI |
|---|---|---|
| R61 | Misrouted Return – Return entry was sent by RDFI to an incorrect ODFI routing/transit number | RDFI should resubmit return to the correct ODFI routing/transit number |
| R67 | Duplicate Return – ODFI has received more than one return entry for the same original entry | RDFI should research returns, and contest with return code R75 if no duplication can be found |
| R68 | Untimely Return – Return entry did not meet the return deadline | RDFI should verify timeliness of return entry, and submit contested dishonored return if necessary (R73) |
| R69 | Field Errors – One or more of the following fields contains incorrect information. Addenda Record Information Field Codes: ∙ 01 Incorrect DFI Account Number ∙ 02 Incorrect Original Entry Trace Number ∙ 03 Incorrect Dollar Amount ∙ 04 Incorrect Individual Identification Number ∙ 05 Incorrect Transaction Code ∙ 06 Incorrect Company Identification Number ∙ 07 Invalid Effective Entry Date | RDFI should submit corrected return with the correct information (R74) |
Contested Dishonored/ Corrected REC
| Dishonored Return Code (Submitted by RDFI) | Code Explanation |
|---|---|
| R71 | Misrouted Dishonored Return – ODFI misrouted the Dishonored Return entry to the wrong RDFI using an incorrect routing/transit number |
| R72 | Untimely Dishonored Return – ODFI did not submit the Dishonored Return entry within the 5 day deadline |
| R73 | Timely Original Return – RDFI certifies that the original return entry was submitted within the applicable deadline |
| R74 | RDFI is correcting a previous return entry that was dishonored using Return Code R69 because it contained incomplete or incorrect information |
| R75 | Original Return Not a Duplicate – The original return entry was not a duplicate of an entry previously returned by the ODFI. This code may be used by the RDFI to contest an entry dishonored by the ODFI using Return Code R67 (Duplicate Return) |
| R76 | No Errors Found – The original return entry did not contain the errors indicated by the ODFI in the Dishonored Return Entry bearing Return Code R69 (Field Errors) |
Standard Entry Class (SEC) Codes
| Code | Application Title | Application Description | Account Type | Transaction Type |
|---|---|---|---|---|
| ARC | Accounts Receivable Check | Converted checks received via the US mail or at a drop box location | Consumer accounts only | Single debit only |
| CCD | Corporate Credit or Debit | Transfer of funds between business accounts or to consolidate funds from several accounts of the same business | Business accounts only | Debit or credit |
| CIE | Customer Initiated Entry | Credit entry originated by an individual (usually through a bill payment service) used to pay some sort of obligation | Consumer or business accounts | Credit only |
| CTX | Corporate Trade Exchange | Payment or collection of commitments between separate businesses | Business accounts only | Debit or credit |
| DNE | Death Notification Entry | Notice entered by an agency of the Federal government to advise an RDFI of the death of an individual (Includes addenda record with details) | Consumer accounts only | Credit only (Non-dollar amount entry) |
| PPD | Prearranged Payment and Deposit Entry | Repeating entry for direct deposit of payroll, pension, etc., or for payment of recurring bills such as utilities, loans, insurance, etc. | Consumer accounts only | Debit or credit |
| RCK | Represented Check Entry | Merchant collection of checks that had been returned as NSF or Uncollected Funds | Consumer accounts only | Single debit only |
| TEL | Telephone Authorized Entry | TEL Entry submitted following an oral authorization obtained solely via the telephone | Consumer accounts only | Single debit only |
| WEB | Internet Authorized Entry | Entry submitted pursuant to an authorization obtained solely via the Internet | Consumer accounts only | Debit only |