Commerce Web Services

Transaction Processing Overview

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

The Authorization Process

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)

The Capture Process

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:

Transaction 00001 and 00005 have been authorized and automatically flagged for capture using the AuthorizeAndCapture() operation.
Transaction 00002, 00003, 00004, and 00006 are also authorized using the Authorize() operation, but not yet captured for settlement.
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.

Terminal Capture vs. Host Capture Platform

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:

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.
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.

Operation Flows: 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 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.

Operation Flows: Bankcard - Host Capture

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:

AuthorizeAndCapture performs an authorization of funds (based on availability) and updates the transaction CaptureState to 'ReadyForCapture' on the service provider host.
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.

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