Velocity Developer Resources

API DOCS MENU

Transaction Processing

The following information provides developers with an understanding of the authorization, capture, and settlement processes as they relate to the Transaction Processing operations available in the Commerce Web Services SOAP/REST API, as well as the typical application workflows associated with each of these processes.

Understanding the Authorization Process

Transaction processing workflows typically begin with an authorization process, which verifies the availability of funds in the cardholder’s account. There are two primary “entry point” authorization operations to consider when beginning your implementation—AuthorizeAndCapture and Authorize.

• AuthorizeAndCapture – This operation is used to authorize and capture a transaction in a single invocation; meaning the availability of funds is authorized and the transaction is captured (flagged) for settlement.
• Authorize – This operation is used to simply authorize a transaction, but it must still be captured for settlement by invoking either the Capture, CaptureAll, or CaptureSelective operation before funds are transferred.

The difference between the AuthorizeAndCapture and Authorize operations is illustrated below.

Figure 12: AuthorizeAndCapture vs. Authorize

Transactions authorized using the AuthorizeAndCapture operation are automatically captured for settlement in a single invocation. Transactions authorized using the Authorize operation are not flagged for settlement, and must be captured manually by invoking CaptureAll or CaptureSelective prior to settlement.

As a result of this subtle difference between the AuthorizeAndCapture and Authorize operations, two possible implementation workflows exist and are driven in large part by the type of service provider system that the merchant will transact against; either Terminal Capture or Host Capture.

Additional guidance can be found by referring to Operation Flows: Bankcard – Terminal Capture and Operation Flows: Bankcard – Host Capture.

Determining the Service Provider Host Type

The service provider’s host type (Terminal Capture/Host Capture) can be determined by looking at the value of the CreditAuthorizeSupport enumeration returned in the response to the GetServiceInformation request (ServiceInformation.Tenders.CreditAuthorizeSupport).

CreditAuthorizeSupport Value	Host Type
AuthorizeAndCaptureOnly	Terminal Capture
AuthorizeOnly	Host Capture
Both	Host Capture (supporting both AuthorizeAndCapture and Authorize application workflows)

Understanding the Capture Process

Once a transaction has been authorized, it must be captured and settled to complete the transaction processing workflow. To avoid possible confusion associated with the concepts of transaction capture and settlement, consider the following definitions:

• Capture – The process of “flagging” a transaction for settlement in the transaction database, either immediately after authorization or at an appointed time determined by the service provider.
• Settlement – The process of transferring funds from one account to another. Applicable interchange fees are also charged to the merchant at the time of settlement.
• Batch – A collection of one or more captured transactions to be settled.

In this section we will discuss the following topics:

• The Capture Operations
• Understanding Terminal Capture and Host Capture Platforms

The Capture Operations

To better understand the capture and settlement process, we must first discuss the difference between the Capture, CaptureAll, and CaptureSelective operations as they relate to the specific workflow requirements of the application.

• Capture – Invoked to flag a single, previously authorized transaction for settlement.
• CaptureAll – Invoked to flag all transactions that have been previously authorized for settlement.
• CaptureSelective – Invoked to flag a specific list of transactions (by transactionId) that have been previously authorized for settlement.

While each operation fundamentally performs the same action—flagging transactions for settlement—they provide the flexibility to determine which transactions are captured and when.

The capture process is illustrated below.

Figure 13: Capture, CaptureAll, CaptureSelective

Transaction 00001 and 00005 have been authorized and automatically flagged for capture using the AuthorizeAndCapture operation. Transaction 00002, 00003, 00004, and 00006 have also been authorized using the Authorize operation, but they have not yet been captured for settlement.

To flag transaction 00002 for capture, the Capture operation is invoked (where transactionId=’00002′). Similarly, transactions 00003, 00004, and 00006 have been flagged for capture using the CaptureSelective operation (where transactionId=’00003′, ‘00004’, ‘00006’), which allows multiple transactions to be flagged by specifying a list of transactions by transactionId.

Depending on the requirements of the application and the specific capabilities of the service provider the merchant is processing with, you must provide the flexibility to invoke the necessary Capture* operations to ensure the desired transactions are captured and transmitted to the service provider for settlement. Transactions that have not been captured are excluded from the batch.

Important! Defining the service provider type(s) the application will support (Terminal Capture and/or Host Capture) is critical before beginning the application development process.

Understanding Terminal and Host Capture Platforms

Understanding the difference between Terminal Capture and Host Capture platforms is critical to understanding the transaction capture and settlement process.

Terminal Capture

Terminal Capture platforms process funds, referred to as transaction settlement, only when specifically instructed to do so. As a result, Terminal Capture hosts require end-of-day settlement of all authorizations and returns processed throughout the day through a batching process in order to complete the funding process. Batching of all transaction records is accomplished through the creation and transmission of what’s referred to as a settlement file.

Note: When invoking the CaptureSelective operation in Terminal Capture environments, Return* transactions should be included (by transactionId), while Undoo

Host Capturee

Host Capture platforms conduct automatic, end-of-day settlement processing for all transactions (with a CaptureState of ‘ReadyForCapture’) without requiring further action from the merchant. Transactions authorized throughout the day are recorded and stored in a database on the service provider’s processing host. In situations where a change to the original transaction amount is required after initial authorization (such as Capture, negative adjustment), such changes must be transmitted to the service provider.

Two primary conveniences of Host Capture platforms include:

• Typically only a transaction ID and relevant metadata needs to be stored by the application subsequent to the initial authorization.
• Host Capture reduces the chance that merchants will be charged higher interchange rates due to failure to meet industry guidelines associated with prompt transaction settlement. Typically, the first downgrade (resulting in higher interchange rates) occurs 24 hours from the time of a transaction’s initial authorization. It is important to note that the “aging off” of a transaction is against Visa and MasterCard mandates. When using the flow of Authorize > Capture, it is best to capture within 24 hours. If a transaction is not captured after 7 days (aging off period), the application should Undo the original Authorize transaction and implement either Tokenization or some process to initiate the authorization process again.

Batch Release Support
Host Capture service providers that support batch release provide merchants with a manual method for settling transactions by triggering immediate processing of all captured transactions; resulting in merchant settlement and funding prior to the cut-off time established by the service provider.

If manual settlement is not triggered by the application within a 24-hour period, all captured transactions are settled automatically based on the settlement cut-off time established by the service provider.

Interchange

Interchange are fees charged to merchants by the major card brands (Visa, MasterCard, American Express, Diners, and Discover) for processing Credit or PIN Debit transactions. This is a base component of the total fees paid by merchants. Interchange fees are assessed on a per-transaction basis.

There are a number of factors that can impact interchange. Some of these factors include timeliness of settlement, completeness of transaction data, and industry data requirements such as AVS data for MOTO transactions and CVV data for eCommerce transactions.

For additional guidance regarding Termnal Capture, Host Capture, batch release support, or interchange, contact your NAB Velocity Sales Engineer.

Operation Flows

The following Transaction Processing operation flows describe the typical order in which specific operations are invoked when supporting the Bankcard Processing (BCP), Electronic Checking (ECK/ACH), and Stored Value Account (SVA) service classes.

Note: The Bankcard Processing (BCP) operation flows above have been split up by processing host type—Terminal Capture and Host Capture, as well as by industry type—Retail, Restaurant, eCommerce, and MOTO.

For additional guidance regarding the most appropriate transaction processing operation flows for your payment solution, contact your NAB Velocity Sales Engineer.

Bankcard – Terminal Capture

Unlike Host Capture platforms which store transactions on the service provider processing host, Terminal Capture platforms require merchants to settle all transactions using either CaptureAll or CaptureSelective.

The following Terminal Capture operational flows are valid for Credit and PIN Debit Bankcard transactions:

Note: AuthorizeAndCapture operation should always be used for PIN Debit transactions regardless of processing host type.

Authorize should be used for all Credit transactions and must be included in a settlement file using CaptureAll or CaptureSelective.

Supported Industry	Description	Operation Flows
Retail and Restaurant	Applications for the Retail and Restaurant industries are typically associated with the purchase of goods in a customer-present, brick and mortar merchant locations. Restaurant transactions typically require the adjustment of a previously authorized transaction amount prior to settlement to accommodate activities, such as the collection of a gratuity.	Authorize > Adjust/Undo > CaptureAll/CaptureSelective > ReturnById/ReturnUnlinked
eCommerce and MOTO	Applications for the eCommerce and MOTO industries are typically associated with the purchase of goods in customer-not-present/card-not-present environments. Note: As a best practice for a card-not-present solution it’s recommended that both AVS and CVV is collected. Please be aware that a transaction can be approved; however, both AVS and CVV can result in a no match. In this case it’s up to the merchant to decide if they wish to assume the risk of settling the transaction even though a match was not made. If the merchant decides to not assume the risk, an Undo should be performed to release the funds. If the service provider supports Verify, the software should perform a verify first to check AVS and CVV and then process and Authorize if a match is found.	Authorize > Adjust/Undo > CaptureAll/CaptureSelective > ReturnById/ReturnUnlinked

Note: Adjustments to transactions must occur before settlement. Once a transaction has been settled, the transaction can only be refunded using either the ReturnById or ReturnUnlinked operations.

When performing CaptureSelective, ReturnById and ReturnUnlinked transactionsIds must be included.

Important! When performing CaptureAll or CaptureSelective on Terminal Capture platforms, settlement times of up to 5 minutes or more are not uncommon depending on the number of transactions in the batch. Client applications need to anticipate and account for longer settlement processing times in their timeout management schemes. Software companies should consider implementing CaptureAllAsync or CaptureSelectiveAsync along with the Transaction Management Service (TMS) API to query for the results.

Additional, Optional Operations (such as QueryAccount and Verify) may also be implemented as application requirements dictate.

For additional guidance regarding the most appropriate operation flows for your payment solution, contact your Implementation Support Specialist.

Bankcard – Host Capture

Unlike Terminal Capture platforms which requires manual settlement of transactions using either the CaptureAll or CaptureSelective operations, Host Capture platforms store all transactions on the service provider processing host and perform automatic, end-of-day settlement processing for all transactions (where CaptureState=’ReadyForCapture’) without requiring further action from the merchant.

Host Capture services support two implementation options for Credit processing— AuthorizeAndCapture and Authorize (pre-authorization).

• AuthorizeAndCapture performs an authorization of funds (based on availability) and updates the transaction’s CaptureState to ‘ReadyForCapture’ on the service provider host.
• Authorize performs the same authorization of funds, but it does not update the transaction’s CaptureState to ‘ReadyForCapture’. When the service provider initiates the daily settlement of all transactions, all authorized transactions will be omitted. To mark the authorized transactions as ‘ReadyForCapture’, the application must invoke the Capture operation.
• Note: Transactions omitted from settlement for more than 24 hours may incur higher interchange fees. Transactions omitted from settlement for more than 7 days may “age off”, which is not allowed by Visa and MasterCard mandates.

The following Host Capture operational flows are valid for Credit and PIN Debit Bankcard transactions:

Note: AuthorizeAndCapture operation should always be used for PIN Debit transactions.

Supported Industry	Description	Operation Flows
Retail and Restaurant	Applications for the Retail and Restaurant industries are typically associated with the purchase of goods in customer-present, brick and mortar merchant locations. Restaurant transactions typically require the adjustment of a previously authorized transaction amount prior to settlement to accommodate activities, such as the collection of a gratuity.	Flow #1: AuthorizeAndCapture > Adjust/Undo > ReturnById/ReturnUnlinked Flow #2: Authorize > Adjust/Undo > Capture > ReturnById Note: If the Undo is declined as the result of the capture of funds by the service provider, you must call ReturnById.
eCommerce and MOTO	Applications for the eCommerce and MOTO industries are typically associated with the purchase of goods in customer-not-present/card-not-present environments. Note: As a best practice for a card-not-present solution it’s recommended that both AVS and CVV is collected. Please be aware that a transaction can be approved; however, both AVS and CVV can result in a no match. In this case it’s up to the merchant to decide if they wish to assume the risk of settling the transaction even though a match was not made. If the merchant decides to not assume the risk, an Undo should be performed to release the funds. If the service provider supports Verify, the software should perform a verify first to check AVS and CVV and then process and Authorize if a match is found.	Flow #1: AuthorizeAndCapture > Adjust > ReturnById/ReturnUnlinked Flow #2: AuthorizeAndCapture > ReturnById/ReturnUnlinked Flow #3: Authorize > Adjust/Undo > Capture > ReturnById Note: If the Undo is declined as the result of the capture of funds by the service provider, you must call ReturnById.

Note: Adjustments to transactions must occur before settlement. Once a transaction has been settled, the transaction can only be refunded using either the ReturnById or ReturnUnlinked operations.

Additional, Optional Operations (such as QueryAccount and Verify) may also be implemented as application requirements dictate.

Batch Release Support

If the service provider supports batch release, the application may trigger settlement of transactions daily by invoking the CaptureAll operation.

For additional guidance regarding the most appropriate operation flows for your payment solution, contact your NAB Velocity Sales Engineer.

Automated Clearing House

The following Automated Clearing House operation flows are valid for each ACH transaction type listed below:

Transaction Type	Operation Flows
Check Authorization	Authorize Authorize > Undo
Capturing Check Transactions	CaptureAll
Account Balance Inquiries	QueryAccount

Stored Value Account

The following Stored Value Account operation flows are valid for each SVA transaction type listed below:

Transaction Type	Operation Flows
ACTIVATE	ManageAccount
ACTIVATE > VOID	ManageAccount > Undo
RELOAD	ManageAccount
RELOAD > VOID	ManageAccount > Undo
DEACTIVATE	ManageAccount
BALTXFR (Balance Transfer)	ManageAccount
STATUS	ManageAccount
STATUS > VOID	ManageAccount > Undo
REDEEM	Authorize
REDEEM > REDEEM	Authorize > Capture
REDEEM > RETURN	Authorize > ReturnById Authorize > Capture > ReturnById
REDEEM > VOID	Authorize > Undo
RETURN	ReturnUnlinked
BALINQ (Balance Inquiry)	QueryAccount

Updated: June 2, 2017