Why Adopt Convenient Checkout V2
Convenient Checkout V2 expands the checkout and wallet experience with coordinated split-tender payments and an HSA-aware wallet experience. Together, these capabilities give customers more flexibility at checkout and clearer ways to understand and manage the payment methods they intend to use for healthcare spending.
Use the V1 to V2 Migration Guide to plan adoption. For capability-specific guidance, see the Split Tender Integration Guide and Widget Capabilities.
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.
HSA-aware wallet capabilities are optional and availability depends on the approved merchant and release configuration. A customer-applied HSA designation is informational: it does not verify a card's issuer, ownership, or eligibility and does not change a card into the separate HSA payment-method type.
Key Benefits
V2 Capability Value
V2 creates value at two different points in the customer journey: split tender adds flexibility when the customer completes a payment, while HSA-aware capabilities add context when the customer views and manages payment methods in the wallet.
| Capability | Business value | Functional and UX impact |
|---|---|---|
| Split Tender | Gives customers another way to complete a payment when one card does not cover the full amount. | A customer can allocate one sale payment across two cards and receive one coordinated result. |
| HSA-aware wallet | Gives eligible customers more context and guidance when managing cards for HSA spending. | Balance display, customer card designation, and the Add HSA Card CTA address distinct customer needs described below. |
More Flexible Payment Completion
| Area | V1 Today | V2 After Migration |
|---|---|---|
| Split Tender | Not supported — one payment method per transaction | Customers can pay with two cards in a single checkout (e.g., FSA/HSA card + credit card) |
| Checkout flow | Fixed, single-path checkout | Flexible multi-card checkout in one flow, with customer-defined split amounts |
| Customer experience | Customer must split the bill manually across separate transactions | One checkout and one confirmation, with the customer selecting cards and assigning split amounts before submission |
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.
HSA-Aware Wallet Capabilities
The HSA-aware wallet experience addresses three customer needs:
Informational HSA Balance
Eligible customers can see HSA balance information while reviewing payment choices. The balance provides account context, but it is not a payment method and is not associated with a stored or designated card.
Customer HSA Designation
Customers can designate one supported card so it is easier to recognize for HSA spending, then remove or reassign the designation. The designation does not verify issuer, ownership, or eligibility, and it does not change normal payment behavior. See Customer HSA Designation on Cards for the complete business rules, wallet presentation, and limitations.
Add HSA Card CTA
When the approved display conditions are met, the CTA makes the add-card journey easier to find and opens the existing experience with the HSA designation selected. It does not validate or prepopulate the card, and exiting without saving leaves the wallet unchanged.
Card presentation and reporting are supporting considerations for the designation. Approved naming and artwork can help identify the designated card, and reporting may provide informational context where supported. Neither is proof of a verified HSA payment method.
How It Works
Split tender coordinates how a sale payment is divided between cards. HSA-aware wallet capabilities provide account context and customer-managed card designation without changing payment authorization or completion.
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.
| Combination | Supported in V2 |
|---|---|
| FSA/HSA card + Credit card | Yes |
| Two credit cards | Yes |
| FSA/HSA card + Bank account (ACH) | No |
| Credit card + Bank account | No |
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.
For HSA-aware wallet capabilities:
- The customer-applied designation remains attached to a supported card and does not change its payment-method type.
- The current wallet context supports one customer-designated HSA card at a time.
- Informational balance visibility and customer card designation are separate capabilities.
- Applying or removing the designation does not change normal card authorization or completion.
- Unavailable optional HSA context must not prevent access to stored payment methods or payment completion.
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 exclusivelyPAYMENT_WITH_WALLET. - At least one card payment method is configured: The session must include a
CARDpayment method; sessions with onlyBANK_ACCOUNTentries 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
| Scenario | Outcome |
|---|---|
| FSA card covers full amount | Single payment processed; split tender not triggered |
| FSA card covers partial amount, credit card covers remainder | Both cards charged (sale) in one session; single confirmation issued |
| Merchant attempts split tender on an authorize-only flow | Session rejected; split tender is not supported for authorize-only payments |
| Customer attempts split tender with a bank account | Session 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 succeeds | First charge reversed automatically; customer prompted to provide an alternative card |
| Customer allocates more than the transaction total | Session rejected before processing; customer asked to correct amounts |
| Customer allocates less than the transaction total | Session rejected before processing; shortfall must be covered by the second card |
Edge Cases
- 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 must apply to the original payment allocations. Merchants should follow the migration and refund integration guides for full-refund and partial-refund behavior.
- 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
trueand the resolved payment method is only bank account, the session is not rejected; the response returns split tender asfalseand the split-tender toggle is disabled. - HSA terminology: Confirm whether “HSA card” means a customer-designated card or the separate HSA payment-method type; the terms are not interchangeable.
- Balance and card shown together: Do not infer that the displayed balance belongs to the customer-designated card.
- Unavailable HSA context: Optional HSA balance or designation presentation must not be treated as a payment outage or as evidence that another payment method is unavailable.