Velocity Developer Resources

API DOCS MENU

Supported Payment Services

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.

Important note about service class-specific development objects:

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.

Bankcard Processing (BCP)

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.

Credit Transactions

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

PIN Debit Transactions

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.

• Online – Requires a Personal Identification Number (PIN) to complete transactions. Because this PIN provides real-time verification of the availability of funds in the cardholder’s checking account, PIN Debit also allows “cash back” transactions, in addition to typical sale transactions. With online debit transactions, the customer must have an available balance in their account that is equal to or greater than the sale amount (plus any cash back amount) in order to complete the transaction.
• Offline – Also referred to as Signature Debit, Offline PIN Debit requires the cardholder’s signature to complete the transaction, but follows the typical Credit processing workflow rather than relying on debit networks. With offline debit, there is no specific check of the cardholder’s checking account balance at the time of the authorization.

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

 

---

 

Electronic Checking (ECK)

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.

SEC Codes

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.

---

Stored Value Account (SVA)

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.

Stored Value Card Types

There are tywo types of Stored Value cards—open loop and closed loop.

• Open Loop – Cards issued by banks or credit card companies that can be redeemed by any establishment that accepts that card brand. The card is identified by a specific number or code, but not the recipient’s name, making it usable by anybody who has possession of the card. Open Loop cards are backed by an on-line electronic system for authorization, and some open loop cards can be reloaded and used multiple times.
• Closed Loop – Cards that can only be redeemed by the issuing provider, such as a specific retailer or restaurant. “Hybrid closed loop” cards allow for the bundling of several closed loop cards, such as cards that can be used across many retailers, such as at a shopping mall.

Updated: June 2, 2017