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()– 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
CaptureAll()operation before funds are transferred.
As a result of the subtle difference between the
Authorize() operations, the implementation workflows are driven by the type of service provider system the merchant transacts against – either Terminal Capture or Host Capture.
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 (
|CreditAuthorizeSupport Value||Host Type|
|Both||Host Capture (supporting both
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.
The difference between the
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:
Authorize()operation, but not yet captured for settlement.
Capture()operation is invoked (where
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.
Service provider host systems are grouped into two categories—Terminal Capture and Host Capture to capture and settle transactions.
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 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:
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 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:
AuthorizeAndCaptureoperation should always be used for PIN Debit transactions regardless of processing host type.
Authorizeshould be used for all Credit transactions and must be included in a settlement file using
|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.||
|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
transactionsIds must be included.
CaptureAllon 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
CaptureAllAsyncalong with Transaction Management Service (TMS) API to query for the results.
Optional Operations (
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:
AuthorizeAndCaptureperforms an authorization of funds (based on availability) and updates the transaction
CaptureStateto ‘ReadyForCapture’ on the service provider host.
Authorizeperforms 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
The following Host Capture operational flows are valid for Credit and PIN Debit Bankcard transactions:
AuthorizeAndCaptureoperation 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:
Note: If the
|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
Note: If the
Additional optional operations (such as
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
For additional guidance regarding the most appropriate transaction processing operation flows for your payment solution, please contact EVO Snap* Support.