API Docs
Commerce Web Services supports the integration of transaction processing for the Bankcard Processing (BCP), Electronic Checking/Automated Clearing House (ECK/ACH), and Stored Value Account (SVA) service classes.
This section will provide you with a fundamental understanding of each of these service classes to help you during your payment processing integrations.
Bankcard Processing (BCP) Objects
When integrating Bankcard Processing services into the application, the Transaction data type should always be replaced with BankcardTransaction, and the Response return type should always be replaced with BankcardTransactionResponse. Similarly, the Capture data type should always be replaced with BankcardCapture and the Return data type should always be replaced with BankcardReturn.
Electronic Checking (ECK) Objects
When integrating Electronic Checking services into the application, the Transaction data type should always be replaced with ElectronicCheckingTransaction, and the Response return type should always be replaced with ElectronicCheckingTransactionResponse.
Stored Value Account (SVA) Objects
When integrating Stored Value Account services into the application, the Transaction data type should always be replaced with StoredValueTransaction, and the Response return type should always be replaced with StoredValueTransactionResponse and StoredValueCaptureResponse.
Commerce Web Services supports the Bankcard Processing (BCP) service class and the Credit and PIN Debit transaction classes. Below is a brief overview of each of these transaction classes supported by CWS.
The Credit transaction class is associated with the lending of funds to the cardholder by an issuing bank in alliance with a card association, such as Visa, MasterCard, or directly by a credit company such as American Express, Discover, and others. Credit transactions are for “total amount of purchase” only, based on an established line of credit to purchase goods or services.
A typical Credit transaction workflow is illustrated below.
Figure 4: Credit Transaction Workflow
Unlike Credit transactions, PIN Debit transactions are associated directly with the cardholder’s bank account (checking or savings) as opposed to a line of credit. During transaction authorization, the verification of available funds is performed to ensure the cardholder has sufficient funds in their account to cover the cost of the purchase.
Debit cards commonly carry a card association brand, but are not required to do so. The appearance of card association branding on a debit card generally ensures wider acceptance, such as at merchants who accept Visa and MasterCard credit cards, as well as at ATM locations not owned by the issuing bank. A common type of debit card is an Automated Teller Machine (ATM) card.
There are two primary types of PIN Debit transactions—Online and Offline.
There are trade-offs for the merchant when accepting Credit vs. PIN Debit transactions, such as liability for fraud reimbursement, transaction fees (referred to as interchange), authorizing against the funds in a bank account, etc.
A typical PIN Debit transaction workflow is illustrated below.
Figure 5: PIN Debit Transaction Workflow
Commerce Web Services supports the Electronic Checking (ECK) service class—supporting the Automated Clearing House (ACH) and Electronic Checking (ECK) transaction classes. ACH transactions leverage existing, inter-bank networks between financial institutions, to process and exchange funds. ECK transactions leverage check authorization and/or guarantee companies to assure retailers that funds are present in the payee’s account, while check guarantee services ensure checks will not be returned due to account closure or insufficient funds once deposited.
Electronic check acceptance is for businesses that want to expedite their cash flow from the traditional paper processing of checks. Business that receive a lot of checks—such as accounts receivable entries, back office conversion, point of purchase, pre-authorized bill payment, check payment over the phone and Internet—can be converted to ACH, reducing funding time and trips to the bank, and bank-assessed paper check processing fees. It also provides ways to handle checks returned for insufficient funds, such as electronic representment.
ACH transactions are initiated from the merchant’s payment software.
A typical ACH transaction workflow is illustrated below.
Figure 6: Automated Clearing House (ACH) Transaction Workflow
For more information about the rules governing ACH transactions, refer to the Electronic Payments Association (NACHA) website.
CWS support for the Automated Clearing House (ACH) transaction class includes the following Standard Entry Codes (SEC):
SEC Code | Description |
Back Office Conversion (BOC) | A single-entry debit initiated by merchant/biller at the point of purchase or at a manned bill payment location after receiving a physical check (source document) provided by the customer. The check is then converted to an ACH debit entry during back-office processing. BOC conversions require the customer to be present. |
Corporate Cash Disbursement (CCD) | Business-to-business transactions. A CCD entry allows for a debit or credit from one organization to another organization. Authorization rules for consumer entries do not apply. |
Prearranged Payment and Deposits (PPD) | Used to credit or debit a consumer’s account. A consumer must provide a written authorization for this payment type to the merchant/biller to automatically debit their savings and/or checking account for a specified dollar amount. The payment types may be a one-time entry or recurring transactions such as membership dues, rent collection, lease payments, or subscription services. |
Telephone-Initiated Entry (TEL) | Initiated based on a verbal authorization by telephone to issue an ACH entry, such as checks, by phone. The merchant/biller must either make an audio recording of the oral authorization, or provide the receiver with written notice confirming the authorization prior to settlement date. |
Web-Initiated Entry (WEB) | Refers to an electronic authorization through the Internet to initiate a transfer of funds from a consumer’s account. NACHA requires that each merchant/biller that originates WEB entries must employ commercially reasonable methods of authentication to verify the identity of the receiver. |
Note: SECCodes is an Electronic Checking enumeration. For more information, refer to the Electronic Checking Enumerations in the CWS Developer API Reference.
Commerce Web Services supports the Stored Value Account (SVA) service/transaction class. Stored Value Accounts are card-based payment systems that assign a specific value to the card. Such cards are often referred to as gift cards or pre-paid cards. The card’s value is stored on the card itself (on the magnetic stripe or in a computer chip) or in a network database. As the card is used for purchases, the total of each transaction amount is subtracted from the card’s balance. As the balance approaches zero, some cards can be “reloaded” through various methods and others are designed to be discarded.
Some banks use gift card systems in lieu of checks as a way to disburse rebate funds, while retailers use the gift card system for refunds in lieu of cash, thereby assuring that the customer will spend the funds at their store.
There are tywo types of Stored Value cards—open loop and closed loop.
Updated: June 2, 2017
SUBMIT A DEVELOPER SUPPORT REQUEST
Agent or a merchant? Contact NAB support at 866.485.8999 EXT 2341