Cardknox is now Sola
Learn More
LogoLogo
Contact Us
  • Introduction
  • 🔗API
    • Transaction API
      • Credit Card
      • Check (ACH)
      • EBT
      • Gift Card
      • Fraud
    • Customer and Recurring API
    • Reporting API
    • Account Boarding API
      • Account Boarding Merchant Agreement
      • Account Boarding Swagger UI
    • Code Samples
    • Error Codes
  • 📦SDK
    • .NET SDK
      • Transaction Workflow
    • iOS SDK
      • iOS SDK - Technical Guide
      • Workflow
    • Android SDK
      • Android SDK - Technical Guide
  • 🧰 Cardknox Products
    • 3D Secure 2.0
      • Client-Side Integration
        • Client-Side Integration (Non-iFields)
      • Server-Side Integration
    • Account Updater
    • Batch Processing
    • Browser-Based POS systems (BBPOS)
    • CloudIM Developer Guide
    • Deep Linking
      • Deep Linking Integration for Third-Party Websites
    • EBT Online
    • Gateway Emulators
    • iFields
      • Angular iFields
    • Merchant Portal
      • FAQ
    • Mobile App
    • Split Capture
    • Tap to Phone - Android
    • Partner Portal
    • PaymentSITE
      • QR Codes for PaymentSITE
    • Webhooks
  • 📱Mobile Wallets
    • Apple Pay Hosted Checkout
      • Apple Pay Hosted Checkout Initial Setup
      • Apple Pay Prerequisites
      • Apple Pay Hosted Checkout Objects Reference (Request)
      • Apple Pay Hosted Checkout Objects Reference (Response)
      • Apple Pay iFields Integration
      • Apple Pay Hosted Checkout Sample Code
      • Apple Pay Features
      • Set up Apple Pay Merchant ID with Cardknox
    • Click-To-Pay - Hosted Checkout
      • Click-To-Pay Initial Setup
      • Click-To-Pay Sample Code
      • Click-To-Pay iFields Integration
      • Click-To-Pay Objects Reference (Request)
      • Click-To-Pay Objects Reference (Response)
    • Google Pay Hosted Checkout
      • Google Pay Control Object
      • Google Pay Request Objects
      • Google Pay Response Objects
      • Google Pay Sample Code
      • iFields Integration
      • Google Pay FAQ
  • 🔌Plugins
    • Netsuite
      • NetSuite Features and Demo
    • WooCommerce
    • Magento Plugin
    • RMH (Retail Management Hero)
    • RMS (Retail Management Systems)
  • 📖Articles
    • Frequently Asked Questions
    • How to Build POS Integration Flows
    • Card Present Integration Guide
  • Glossary of Terms
Powered by GitBook
On this page
  • Overview
  • Transaction Flow
  • CC:AuthOnly Transaction
  • CC:SplitCapture Transaction
  • Follow Up Transactions
  • Closing an AuthOnly Transaction
  • Voids
  • Refunds
  • Reporting

Was this helpful?

Export as PDF
  1. Cardknox Products

Split Capture

Overview

Cardknox’s Split Capture feature enables merchants to capture multiple payments for a single authorization-only transaction. This functionality is ideal for e-commerce merchants who ship out orders in increments, as they have the ability to capture several portions of the authorization as each shipment goes out.

The benefits of Split Capture are as follows:

  • Ability to Confirm Available Funds for the Entire Order Amount Rather than having to process multiple authorizations and captures, merchants can run a single authorization to confirm there are funds available before capturing several portions of the total amount.

  • Improve Record Keeping and Account Reconciliations Using Split Capture helps merchants to ensure that payments more accurately reflect shipments. Invoices and records are more organized, and the account reconciliation process is that much simpler.

  • Customer Satisfaction Customers appreciate that they’re only getting charged for shipments that have actually shipped out.

Transaction Flow

CC:AuthOnly Transaction

A standard authonly command is executed for the amount to be authorized with no additional flags.

  • For the best merchant experience, it is recommended that the transaction include xRequireSplitCapturable=1, which ensures that the transaction can be split captured. If the flag is sent in on the authorization and the account is not set up to support split capture, the transaction errors with, “Split capture not supported.“ This flag is only supported on cc:authonly transactions.

  • If the authorization can be split captured (i.e., the engine and account setup support split captures), then the authonly response includes IsSplitCapturable=1.

Transaction Incoming Fields (Specific to AuthOnly Transactions)

[Optional] flag to require that authorization is able to be split captured before processing the authorization

Field

Value

xCommand

cc:authonly

xRequireSplitCapturable

[Optional] flag to require that authorization will be able to be split captured before processing the authorization

xAmount

Amount to be authorized

CC:SplitCapture Transaction

For a single cc:authonly, many cc:splitcapture commands can be executed. Each cc:splitcapturemust specify the amount of the original authorized amount to be captured. The authorization is updated with the ClearedAmount (amount that was successfully captured) and the ClearedCount (count of successful split capture transactions).

Transaction Incoming Fields (Specific to Split Capture Transactions)

Reference number of the authonly transaction.

Field

Value

xCommand

cc:splitcapture

xRefnum

Reference number of the authonly transaction.

xAmount

Amount to be split captured

Follow Up Transactions

Closing an AuthOnly Transaction

The user has the option to close an authonly transaction so that additional transactions cannot be processed for the authorization.

Once the auth has been closed:

  • The status of the auth would be set to AuthCloseTransaction.

  • In the transaction details of the auth, canceled would be set to true.

  • An auth that was already closed would be blocked.

    • "Auth can no longer be closed"

  • A voided auth would be blocked.

    • "Cannot close voided auth"

  • Additional split captures would be blocked.

  • Voids and refunds on the auth would be blocked.

    • Void: "Authorization was closed and can no longer be voided."

    • Refund: "Refund not allowed. Issue refund on split capture transaction."

Field

Value

xCommand

cc:authclose

xRefnum

Reference number of the authonly transaction.

The close command should only be used to close an authorization that has already been split captured. If a merchant wants to close an authorization that has not been split captured yet, the authorization should be voided.

Voids

  • An auth can not be voided/voidrefunded if it was split captured or closed.

    • "Authorization was split captured. Issue refund on split capture transaction."

  • A split capture transaction can not be voided.

    • “Split capture cannot be voided. Issue refund."

Refunds

  • Refunding an authonly transaction:

    • If the authonly was not captured/split captured or closed, refund would be blocked.

      • “Refund not allowed on non-captured auth. Issue void.”

    • Once the authonly has been split captured, refund would be blocked.

      • “Refund not allowed. Issue refund on split capture transaction.”

  • Refunding a split capture transaction:

VoidRefund

  • AuthOnly Transaction

    • If transaction has not been split captured, it will be processed as a void.

    • If transaction has been split captured, this will be blocked.

  • Split Capture Transaction

    • Transaction will be processed as a refund.

Reporting

Field

Value

xClearedCount

Count of cleared split capture transactions on original auth.

xClearedAmount

Amount that has been split captured on original auth.

xIsSplitCapturable

Specifies whether or not the auth can be split captured.

Report:auth will only display authorizations that have not been closed. It will display authorizations that have been split captured.

Last updated 2 years ago

Was this helpful?

The following fields can be requested on all standard report types. See for more reportable fields.

🧰
here