Transaction Processing Overview

Commerce Web Services

Print Friendly, PDF & Email

Transaction Processing Overview

The following information describes the authorization, capture, and settlement processes related to Commerce Web Services SOAP/REST API Transaction Processing operations.

 

Transaction processing workflows typically begin with an authorization process used to verify the availability of funds in a cardholder account. The two primary entry point authorization operations for your implementation are AuthorizeAndCapture() and Authorize().

  • AuthorizeAndCapture() – An operation used to authorize and capture a transaction in a single invocation, (e.g.: The available funds are authorized and the transaction is captured and flagged for settlement).
  • Authorize() – An operation used to authorize a transaction. The transaction must be captured manually for settlement by invoking a Capture() or CaptureAll() operation before funds are transferred.
 

As a result of the subtle difference between the AuthorizeAndCapture() and Authorize() operations, the implementation workflows are driven by the type of service provider system the merchant transacts against - either Terminal Capture or Host Capture.

 

Determining the Service Provider Host Type

 

The service provider host type (Terminal Capture or Host Capture) can be determined by identifying the value of the CreditAuthorizeSupport enumeration returned in the response to a 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)

Use Capture and Settle to complete the transaction processing workflow once a transaction is authorized.

 

Capture is the process of 'flagging' a transaction for settlement in the transaction database immediately after authorization or at a time specified by the service provider. Settlement is the process of transferring funds from one account to another and applying any associated interchange fees. Batch is a collection of one or more captured transactions ready for settled.

 

Capture Operations

The difference between the Capture() and CaptureAll() operations as they relate to the specific workflow requirements of an application is as follows:

  • Capture() – Invoked to flag a single, previously authorized transaction for settlement.
  • CaptureAll() – Invoked to flag all transactions previously authorized for settlement.
 

Each operation performs a similar action of flagging transactions for settlement and also provides flexibility for a merchant/ISV to specify the transactions to capture and when to capture them. A capture process sample is below:

  1. Transaction 00001 and 00005 have been authorized and automatically flagged for capture using the AuthorizeAndCapture() operation.
  2. Transaction 00002, 00003, 00004, and 00006 are also authorized using the Authorize() operation, but not yet captured for settlement.
  3. To flag transaction 00002 for capture, the Capture() operation is invoked (where transactionId='00002').
 

Depending on the application requirements and the specific capabilities of the service provider processing the merchant transactions, flexibility is imperative to invoke the required Capture() operations to ensure transactions are captured and transmitted to the service provider for settlement. Transactions that have not been captured are excluded from the batch.

 
IMPORTANT! It is critical to define the service provider type(s) (Terminal Capture and/or Host Capture) the application is required to support before beginning application development.
 

Service provider host systems are grouped into two categories—Terminal Capture and Host Capture to capture and settle transactions.

 

Terminal Capture

 

Terminal Capture systems process transaction settlement funds data only when specifically instructed to do so and rely on the transmission of the complete transaction record in the settlement file. All Terminal Capture hosts require manual settlement initiation and rely on the application to upload all transaction data. This type of implementation is beneficial for merchants commonly making regular adjustments to the original transaction amount prior to submission for settlement.

 

Host Capture

 

Host Capture systems conduct automatic, end-of-day settlement processing for all transactions without any action required by the merchant. Transactions authorized throughout the day are recorded and stored in the service provider processing host database. If a change to the original transaction amount is required after initial authorization (adjustments or voids), the change must be transmitted to the service provider.

 

Two benefits of Host Capture:

  1. While an application can store full transaction data, only a transaction ID and relevant metadata is required to be stored by the application subsequent to the initial authorization.
  2. Host Capture can reduce the chance of higher interchange rate charges for delayed transaction settlement since transactions are automatically settled for the merchant.
 

Host Capture BATCHRELEASE

 

Host Capture service providers supporting BATCHRELEASE offer a manual transaction settlement method 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 BATCHRELEASE is supported by the service provider, but manual settlement is not triggered by the application within a 24-hour period, all captured transactions are settled automatically at the pre-determined settlement cut-off time. For additional guidance regarding Host Capture support for BATCHRELEASE, contact your Implementation Support Specialist.

 

Interchange

 

Interchange is the fee charged to a merchant by the major card brands, (Visa, MasterCard, American Express, Diners & Discover), for processing Credit or Debit transactions. This is a base component of the total fees the merchant pays and fees are assessed on a per-transaction basis. A number of factors impact interchange rates including: the timeliness of settlement and completeness of transaction data. For additional guidance related to interchange and other transaction processing fees, contact your Implementation Support Specialist.

Unlike Host Capture platforms, which store transactions on the service provider processing host, Terminal Capture platforms require merchants to settle all transactions using CaptureAll. The following Terminal Capture operational flows are valid for Credit and PIN Debit Bankcard transactions:

Note: The 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.
 
Supported Industry Description Operation Flows
Retail & Restaurant Retail and Restaurant industry applications are generally associated with customer-present purchases in brick and mortar merchant locations. Restaurant transactions often require the adjustment of a previously authorized transaction amount for gratuity collection prior to settlement. Authorize Adjust/Undo; CaptureAll ReturnById/ReturnUnlinked
eCommerce & MOTO eCommerce and MOTO industry application are generally associated with customer-not-present/card-not-present purchase environments. Note: As a best practice for card-not-present solutions, EVO recommends collecting both AVS and CVV data. However, both AVS and CVV can result in a 'no match' on approved transactions. It is up to the merchant to decide to assume the risk of settling the transaction without a match. If a merchant chooses not to assume the risk, the funds must be released via an Undo action. If the service provider supports Verify, perform a verify operation first to check AVS and CVV, and then process an Authorize if a match is found. Authorize Adjust/Undo CaptureAll ReturnById/ReturnUnlinked
Note: Any Adjustments to a transaction must occur prior to settlement. If a transaction is settled, refund is the only action using either ReturnById or ReturnUnlinked operations.
 

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

IMPORTANT! When executing a CaptureAll on Terminal Capture platforms, settlement times up to 5 minutes (or more) are not uncommon, depending on the number of transactions in the batch. Client applications must anticipate and account for longer settlement processing times in the timeout management schemes. Consider implementing CaptureAllAsync along with Transaction Management Service (TMS) API to query for the results.
 

Optional Operations (QueryAccount and Verify) may also be required. For additional guidance regarding the best operation flows for your payment solution, please contact your Implementation Support Specialist.

Unlike Terminal Capture platforms requiring manual settlement of transactions, 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 any action from the merchant.

 

Host Capture services support two implementation options for Credit processing:

  1. AuthorizeAndCapture performs an authorization of funds (based on availability) and updates the transaction CaptureState to 'ReadyForCapture' on the service provider host.
  2. Authorize performs an authorization of funds, but does not update the transaction CaptureState. When a service provider initiates the daily settlement for all transactions, all authorized transactions are omitted. To flag the authorized transactions as 'ReadyForCapture', the application must invoke the Capture operation.
Note: Transactions omitted from settlement for more than 24 hours may be subject to 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: AuthorizeAndCaptureAdjust/Undo ReturnById/ReturnUnlinked Flow #2: Authorize Adjust/Undo CaptureReturnById 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/UndoCapture 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.

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 transaction processing operation flows for your payment solution, please contact EVO Snap* Support.