Card + Card Transaction
Split tender transactions with two cards allow customers to distribute payment for a single order across two different payment cards. This functionality provides flexibility by letting customers combine different card types (credit/debit) or use multiple cards when a single card has insufficient funds.
Scope
- Mode:
Pay With Wallet| API Scope:merchant| API Enpoint:v2/payments| Interaction mode:API - Maximum number of payment methods: 2
- Payment Type:
SALE - Transaction Type: Card + Card
Out-Of-Scope
- Mode:
One Time PayPay & Save| API Scope:merchant-pci| API Enpoint:v2/sessions| Interaction mode:UI - Payment Type:
PRE-AUTH - Transaction Type: Card + ACH / ACH + ACH
Transaction Processing
For detailed information about Card+Card transaction processing, see Split Tender Transaction Processing.
Business Use Case Scenarios
Payment Method Validation
Given Payment Method validation is passed for both the payment methods, refer to Payment Method Validation
Standard Scenarios
Positive Use Cases
| ID | Scenario | User Type | CARD 1 Status | CARD 2 Status | CCG Transaction Status | CCG Actions | CCG Transaction Final Status |
|---|---|---|---|---|---|---|---|
| 1 | Both Card Payments Successful | Customer | AUTHORIZED | AUTHORIZED | ⌛ PENDING | CCG initiate Capture for Both Cards | ✅ COMPLETED |
Positive Flow
Negative Use Cases
| ID | Scenario | User Type | CARD 1 Status | CARD 2 Status | CCG Transaction Status | CCG Actions | CCG Transaction Final Status |
|---|---|---|---|---|---|---|---|
| 2 | Any one card fails | Customer/Agent | AUTHORIZED | FAILED | ❌ PENDING | Transaction rolled back for Card 1 | ❌ FAILED |
| 3 | Any one card requires 3DS AUTH | Customer/Agent | AUTHORIZED | AUTH-REQUIRED | ❌ PENDING | 3DS challenge cannot be completed in API and roll back card 1 | ❌ FAILED |
Edge Case Scenarios
Probability
CAPTURE/CANCEL FAILURES
- The probability of the following edge case scenarios occurring in a live production environment is extremely low (less than 0.1%).
- Most capture and cancel failures are transient and are automatically handled by CCG's built-in retry mechanisms. See Retry mechanism for Stripe calls.
- Based on production data, persistent failures for capture or cancel operations are exceedingly rare and typically result from external system outages or network disruptions.
- If a persistent failure does occur, CCG should follow the recovery strategies for Capture Failures and Cancellation Failures. The appropriate response should be determined based on the impact and volume of affected transactions in production.
Edge Cases
| ID | Scenario | CARD 1 Status | CARD 2 Status | CCG Transaction Status | CCG Actions | CCG Final Status | CCG Transaction Final Status | CCG RollBack Plan | |
|---|---|---|---|---|---|---|---|---|---|
| 5 | CCG Capture Failure | Authorized | Authorized | ✅ AUTHORIZED | CCG Capture fails on one card | ✅ COMPLETED | ❌ FAILED (if Card 2 fails) | ❌ FAILED | Recovery Strategy for Capture Failures |
| 6 | CCG Roll back Failure | Authorized | FAILED | ❌ PENDING | CCG Cancel fails on one card | ❌ AUTHORIZED (cancellation failed) | ❌ FAILED (if Card 2 fails) | ❌ FAILED | Recovery Strategy for Cancellation failure |
Webhook Handling
Refer WebHook management