BankServACH
BankServ is a payment gateway that interfaces with the Automated Clearing House (ACH) network to support online electronic check payments.
Electronic check payments are made in a single transaction and use the automated ACH system operated by the Federal Reserve to debit and credit the appropriate accounts at different financial institutions. This transfer of funds from the debit account to the credit account is known as settlement. Settlement happens automatically after the transaction has been submitted to the ACH network. Every 24 hours, accepted transactions are sent, as a batch, to the BankServ originating bank (ODFI), where they are introduced into the ACH network. The cutoff point is defined to be the time of day where transactions for the prior 24 hours are sent to the bank (which is 2:30 p.m., PST). All transactions after the cutoff point will be sent in the following batch, occurring up to 24 hours in the future. Once the transactions are presented to the Federal Reserve, they will be settled between the debit account and the credit account. Unless voided, from the merchant standpoint, the transaction is a singular event occurring at the time of the sale, that is, there is no separate settlement process. All BankServ transactions result in ACH Debit transactions. The BankServ Gateway does not support ACH Credit due to the fact that an ACH Credit cannot be done systematically at this time.
An electronic check transaction occurs by sending a single request that contains the buyer account details, and the corresponding transaction specific details. Once this request has been authorized by BankServ, it is batched and then sent to the ACH system for automatic settlement. This automatic settlement happens once a day, and as mentioned previously, all transactions occurring after the specific settlement time will be settled the next business day. If the transaction returns from the ACH network, it can be automatically re-presented up to two times by the BankServ ACH system. Re-presentment is most commonly used when a transaction is returned due to insufficient funds. In this scenario, a merchant will typically re-present the transaction in the hopes that the additional funds have been placed into the checking account. BankServ allows the merchant to specify, based on the return code, to automatically re-present a transaction or not (if re-presentment is not automatic, then the merchant must manually deal with the returned transaction). For example, a merchant may set up insufficient funds returns to cause automatic re-presentment, but an account closed would be a hard return requiring manual repair. This gives the merchant the flexibility to define how they want to handle the multitude of return reasons. The number of re-presentments of a transaction to the bank for collection is configurable by the merchant at setup time and is not transaction specific. Transactions should be debited within 48 hours.
The following image shows the major components involved with the Cassette for BankServACH in a WebSphere Commerce Payments environment.
BankServ merchant registration
The BankServ registration process is a manual process between BankServ and the merchant in which the merchant provides:
- A merchant contract.
- A set up form.
- A voided check.
- Financial data.
- The IP address of the machine which will be accessing the server. When accessing the BankServ gateway from behind a firewall using socks or proxy, the merchant must register each of the outgoing IP address(es) of the proxy.
Once BankServ receives and verifies the information, they underwrite the merchant. The BankServACH cassette assumes that this merchant registration process has occurred before attempted use of the cassette.
Merchant PIN
As part of merchant registration, BankServ will assign the Merchant a Merchant PIN. The merchant is identified by the merchant PIN. A merchant PIN is a string of up to 200 bytes long which BankServ has issued. This PIN number is associated with the IP addresses of the merchant servers. If a presented merchant PIN fails to originate from a listed merchant IP address, the transaction will be rejected.
Communications
Communication with the BankServ payment gateway is based on the HTTPS protocol, which uses name/value pairs. TCP/IP is the underlying network architecture. Requests to and responses from the BankServ server take the form of name/value pairs.
General flow
Upon receipt of a Deposit request from the merchant, the cassette establishes a connection to the BankServ payment gateway, sends the transaction information to the BankServ gateway, and synchronously receives the response from BankServ. The connection with the BankServ gateway is not long-lived (that is, a connection is established for each deposit transaction).
Communications via HTTPS
HTTPS is a secure/encrypted version of HTTP. Since all information is sent in an encrypted format, HTTPS is much less vulnerable to network sniffing thus greatly reducing the risks of clandestine theft of information. In addition, HTTPS uses a certificate based identification system to reduce faked identity connections.
Supported functions
The BankServ gateway supports both electronic check and credit card transactions for either known or unknown buyers, only some of which are supported by the BankServACH Cassette.
The following table shows the five types of transactions supported by the BankServ gateway, and whether the Cassette for BankServACH supports the transaction:
| Transaction | Description | Supported by BankServACH Cassette? |
|---|---|---|
| Electronic Check | Submits transaction into BankServ batch to be entered into the ACH system for automatic settlement (which occurs once a day) | Yes |
| Credit Card | Credit card authorization transaction | No |
| Credit Card Settlement | Credit card settlement transaction | No |
| Transaction Report | Contains a summation of all transactions for a specified merchant PIN on a specified date | No |
| Status Transaction | Allows a client to query the status of a specified transaction | Yes (internal use only) |
Electronic check and status transactions are defined by a rule_set. The following table lists the rule_sets and indicates which of these rule_sets will be supported by the Cassette for BankServACH. Based on these existing rules, the cassette can only support ACH Debit transactions with a Standard Entry Class Code (SEC Code) of WEB. WEB Transactions are consumer ACH Debit transactions authorized over the Internet. These non-recurring debit entries are initiated by the Originator based on authorization and account information obtained from the consumer.
| Rule set | Meaning | Supported by BankServACH Cassette? |
|---|---|---|
| ACHDEBIT | ACH Transaction without credit card information for unknown buyer | Yes |
| ACHDEBEX | ACH Transaction without credit card information for known buyer | No |
| TRXSTAT | Transaction status | Yes |
| TSCC | Credit card transaction for unknown buyer | No |
| TCCEX | Credit card transaction for known buyer | No |
| TCCNORQ | Used for internal testing | No |
| ACHVOID | Void an ACH transaction | Yes |
Sensitive data protection
As an option, you can
prevent sensitive financial data from being returned in query results when
users enter query commands. A JVM system parameter called wpm.MinSensitiveAccessRole can
be specified to define the minimum access role a user must have to view sensitive
data returned in query command results. The parameter is by using the
Configuration Manager by setting the Minimum
Access Role field for the Payments instance to a value of clerk, supervisor,
madmin (Merchant Administrator), psadmin (Payments Administrator), or none
(no one is allowed to view sensitive data).
When a user enters a query
by a query command, WebSphere Commerce Payments checks the user's role
against the minimum role specified for the wpm.MinSensitiveAccessRole parameter
and determines whether sensitive data should be returned in full view or masked
out. The following table lists the data elements that are considered sensitive
by the Cassette for BankServACH:
| Data | How data is protected |
|---|---|
| $CHECKROUTINGNUMBER | Buyer's check routing number. The entire value is masked with asterisks. |
| $CHECKINGACCOUNTNUMBER | Buyer's checking account number. The entire value is masked with asterisks. |
If the wpm.MinSensitiveAccessRole parameter is
not specified, an access role of Clerk is assumed, which allows all users
to see sensitive data. If the user's role matches or exceeds the role value,
the actual values are displayed for the sensitive data.