API Docs
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.
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.
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.
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) |
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:
In this section we will discuss the following topics:
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.
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 the difference between Terminal Capture and Host Capture platforms is critical to understanding the transaction capture and settlement process.
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 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:
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 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.
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.
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.
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).
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: 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: Flow #3: 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.
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.
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 |
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
SUBMIT A DEVELOPER SUPPORT REQUEST
Agent or a merchant? Contact NAB support at 866.485.8999 EXT 2341