Skip to main content
Version: v2

Sessions (Split Tender via UI)

Split tender transactions allow customers to pay for a single order using up to two payment methods in a single session. This approach increases payment flexibility, reduces cart abandonment, and supports scenarios where a single payment method is insufficient.

Scope
  • Session Mode: PAYMENT_WITH_WALLET | API Scope: user | API Endpoint: v2/sessions | Interaction mode: UI
  • Maximum number of payment methods: 2
  • Payment Type: SALE
  • Transaction Type: Any
Out-Of-Scope
  • Mode: One Time Pay Pay & Save
  • Payment Type: PRE-AUTH

Transaction Processing​

For UI-based split tender transactions using the Sessions API, the system processes payments in parallel:

  1. Payment Methods Selection: Customer selects both payment methods and allocates amounts (in cents) to each.
  2. Parallel Processing: Both payment methods are processed simultaneously for faster response time.
  3. Transaction Result: System combines both payments and provides a unified result to the customer and merchant.
Parallel Processing

Payment methods in split tender transactions are processed in parallel to optimize transaction processing time and provide a faster checkout experience for customers. If either payment fails, the entire transaction is considered failed and any successful payment is reversed.

Process Flow
UI Session Split Tender Process Flow

User Experience Flow​

  1. Initial Payment Screen: Customer sees saved payment methods and total due (in cents).
  2. Payment Methods Selection: Customer selects both payment methods and allocates amounts (must be ≥ 1¢ each).
  3. Review and Confirm: Customer reviews split and confirms.
  4. Parallel Processing: Both payments are processed at the same time.
  5. Completion: On success, customer is redirected to the merchant's return URL. On failure, clear error and retry options are shown.
UI Validation
  • Amount Limitation
    • Split Tender should not be allowed when amount specified less than 2 cents at parent level
    • Amount should not be allowed to be less than 1 cent at each payment level under split tender transaction
  • ACH Payment
    • If Consent is unavailable, UI should restrict ACH payment
    • Bank accounts cannot be selected for split tender transactions when PRE-AUTH is the payment type, as ACH payments only support sale transactions.
Session Management
Session States for Split Tender Transactions
  • CREATED: Initial state after session creation
  • INITIATED: Consumer has started the payment process
  • ✅ COMPLETED: When payment is ✅ COMPLETED
  • CANCELLED: When session is cancelled
  • EXPIRED: When session is expired
  • ❌ FAILED: Payment method Error
3DS Authentication
3DS Authentication requirements for Card split transactions
  • 3D Secure authentication may be required for either card based on the issuing bank's risk assessment
  • When 3DS is triggered for either card, the authentication will proceed independently
  • Both cards' 3DS authentications can occur simultaneously if needed
  • Failed 3DS authentication on either card will result in the entire transaction being declined
  • For international cards, 3DS requirements may differ based on regional regulations
  • If 3DS authentication times out, the system will consider it a failed authentication
  • Merchants can configure whether to require 3DS based on transaction risk profiles