Checking access…

Skip to main content
Version: v2

Why Migrate to Convenient Checkout V2

Convenient Checkout V2 introduces Split Tender: the ability for a customer to pay a single bill using more than one card within one checkout session. This capability is not available in V1 and is a primary reason merchants migrate.

Get Started

Ready to integrate? See the Split Tender Integration Guide for request and response details, status handling, and a go-live checklist.

Current Scope

Split tender currently supports sale payments only (immediate charge). Authorize-only flows, where funds are held and captured later, are not in scope at this time.

Key Benefits​

Before and After​

AreaV1 TodayV2 After Migration
Split TenderNot supported — one payment method per transactionCustomers can pay with two cards in a single checkout (e.g., FSA/HSA card + credit card)
Checkout flowFixed, single-path checkoutFlexible multi-card checkout in one flow, with customer-defined split amounts
Customer experienceCustomer must split the bill manually across separate transactionsOne checkout and one confirmation, with the customer selecting cards and assigning split amounts before submission

Real-World Example​

A patient owes $350 for a medical visit. Their FSA card covers $200, and they want to pay the remaining $150 with a credit card. In V1, this requires two separate transactions: the patient must calculate the split and submit payments independently. In V2, the customer selects both payment methods in one session, assigns amounts, and submits once. CCG processes both charges and returns a single confirmation.

How It Works​

What Split Tender Covers​

Split tender is currently supported for card payments only and sale payments only (immediate charge at checkout). Both payment method legs must be cards.

Current scope: Authorize-only (two-step hold and capture) is not supported for split tender transactions.

CombinationSupported in V2
FSA/HSA card + Credit cardYes
Two credit cardsYes
FSA/HSA card + Bank account (ACH)No
Credit card + Bank accountNo

Standard Split Tender Flow​

For technical integration details, see the Split Tender Integration Guide.

Business Rules​

Pre-Conditions​

  • The merchant must be onboarded to Convenient Checkout V2.
  • The transaction must be a sale payment (immediate charge); authorize-only flows are not eligible for split tender.
  • The customer must have at least two cards saved in their wallet, or enter a second card at checkout.
  • The total allocated amounts across both cards must equal the transaction total.

Post-Conditions​

  • Each payment method is charged separately; both charges appear in the merchant's reporting extract.
  • If one payment method fails after the other succeeds, the successful charge is automatically reversed.
  • A single session confirmation is returned to the customer covering all payment legs.

Constraints​

  • Split tender is a V2-only capability and cannot be back-ported to V1.
  • Split tender is supported for sale payments only; authorize-only (hold + capture) flows are out of scope.
  • A maximum of two cards per session is supported.
  • FSA/HSA qualified amounts must not exceed the IIAS-qualified portion of the transaction.

Split tender is eligible only when all of the following conditions are met:

  • Session mode is PAYMENT_WITH_WALLET: Split tender is only supported when the session mode is exclusively PAYMENT_WITH_WALLET.
  • At least one card payment method is configured: The session must include a CARD payment method; sessions with only BANK_ACCOUNT entries are not eligible for split tender.
  • Split tender is enabled in merchant settings: The merchant must have split tender enabled in merchant configuration for it to be applicable to the session.

Scenarios​

Split Tender Scenarios​

ScenarioOutcome
FSA card covers full amountSingle payment processed; split tender not triggered
FSA card covers partial amount, credit card covers remainderBoth cards charged (sale) in one session; single confirmation issued
Merchant attempts split tender on an authorize-only flowSession rejected; split tender is not supported for authorize-only payments
Customer attempts split tender with a bank accountSession is not rejected when the request or merchant resolved flag is true and the resolved payment method is only bank account; response sets split tender to false and disables the split-tender toggle.
Second card declines after first succeedsFirst charge reversed automatically; customer prompted to provide an alternative card
Customer allocates more than the transaction totalSession rejected before processing; customer asked to correct amounts
Customer allocates less than the transaction totalSession rejected before processing; shortfall must be covered by the second card

Edge Cases​

Known Limitations
  • Sale payments only: Split tender cannot be used with authorize-only flows. Merchants that use two-step authorization (hold then capture) must collect the full amount on a single card.
  • Refunds on split tender: Refunds are applied back to the original cards in the same proportions as charged. Merchants cannot redirect a refund to a different card than was originally used.
  • FSA/HSA over-qualification: If the FSA amount entered by the customer exceeds the IIAS-qualified amount, the transaction is declined. Merchants should surface the qualified amount clearly in the checkout UI.
  • Resolved bank account behavior: If the request or merchant resolved flag is true and the resolved payment method is only bank account, the session is not rejected; the response returns split tender as false and the split-tender toggle is disabled.