This commit implements Phase 1 of the ConfirmationToken redesign, providing a
drop-in replacement for PaymentMethod-based server-side confirmation flows.

## Core Infrastructure Added

### API Repository Integration
- Add createConfirmationToken() method to StripeRepository interface
- Implement full StripeApiRepository.createConfirmationToken() with Result<T>
- Add PaymentAnalyticsEvent.ConfirmationTokenCreate for tracking
- Support fraud detection data and user agent tracking

### Enhanced ConfirmationTokenCreateParams
- Add productUsageTokens property for analytics attribution
- Update Builder pattern with setProductUsageTokens() method
- Update all factory methods (createWithPaymentMethodCreateParams,
  createWithPaymentMethodId, createCard) with productUsageTokens support
- Maintain full backward compatibility

### Test Infrastructure
- Update AbsFakeStripeRepository with createConfirmationToken() stub
- Add comprehensive unit test suite (42 tests, 100% passing):
  - ConfirmationTokenJsonParserTest.kt (16 tests)
  - ConfirmationTokenCreateParamsTest.kt (17 tests)
  - StripeApiRepositoryConfirmationTokenTest.kt (9 tests)

## Technical Implementation

### Follows Android SDK Patterns
- Uses Result<T> for consistent error handling
- Supports Kotlin coroutines for async operations
- Implements proper Parcelable serialization
- Follows existing JSON parsing conventions

### Production Ready
- Correct /v1/confirmation_tokens API endpoint
- Proper parameter serialization via toParamMap()
- Analytics integration with product usage tracking
- Comprehensive error handling and validation

## Testing & Validation
- All changes compile successfully with no errors
- Unit tests validate JSON parsing, parameter creation, API integration
- Test patterns follow Android SDK conventions (fakes over mocks, Truth assertions)
- No breaking changes to existing PaymentMethod functionality

## What This Enables
ConfirmationTokens solve fragmented MPE data transport by automatically handling:
- setup_future_usage from "Save payment details" checkbox state
- mandate_data generation for payment methods requiring mandates
- shipping address collection from Elements
- cvc_token for server-side CVC recollection
- return_url configuration from client-side

This provides merchants with simplified server-side confirmation integration
and unlocks new Elements features like saved payment methods.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

## Key Changes:
1. **Remove `object` field from ConfirmationToken model** - Following Android SDK pattern where `object` field is only used for JSON parsing validation, not exposed in public API
2. **Make sensitive fields internal** - Applied proper public/internal API boundaries:
   - ✅ **Public**: `id`, `created`, `liveMode`, `returnUrl`, `shipping` (merchant-facing)
   - 🔒 **Internal**: `paymentMethodData`, `paymentMethodOptions`, `mandateData`, `setupFutureUsage` (SDK implementation details)

## Android SDK Pattern Discovery:
- All Stripe API objects (PaymentIntent, Customer, etc.) have `object` field in JSON responses
- But Android SDK models DON'T expose them - only used by JSON parsers for validation
- Example: `CustomerJsonParser` validates `"object": "customer"` but `Customer.kt` has no object field

## Updated API Design:
```kotlin
data class ConfirmationToken(
    val id: String,              // ✅ Public - merchants need for server calls
    val created: Long,           // ✅ Public - expiry validation
    val liveMode: Boolean,       // ✅ Public - environment validation
    val returnUrl: String?,      // ✅ Public - merchant configurable
    val shipping: ShippingDetails?, // ✅ Public - merchant UI display

    internal val paymentMethodData: PaymentMethodData?,     // 🔒 Contains PII
    internal val setupFutureUsage: SetupFutureUsage?,      // 🔒 SDK derived
    internal val paymentMethodOptions: PaymentMethodOptions?, // 🔒 SDK config
    internal val mandateData: MandateDataParams?           // 🔒 Auto-generated
)
```

This provides a clean, secure API surface while maintaining full functionality for server-side confirmation.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

…nCallback interface

- Add ConfirmationTokenResult sealed class with Completed, Failed, and Canceled states
- Add ConfirmationTokenCallback interface with onConfirmationTokenResult method
- Fixes compilation errors in paymentsheet module
- Enables ConfirmationToken callback pattern for PaymentSheet and FlowController integration

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Week 1 Milestone: ConfirmationToken Bindings APIs - COMPLETE

- Add createWithConfirmationToken() factory methods to ConfirmPaymentIntentParams and ConfirmSetupIntentParams
- Enhanced ConfirmationToken model with proper visibility controls and comprehensive documentation
- Updated tests for new confirmation token parameter integration
- All Android API binding infrastructure now complete and tested

API bindings include:
- JSON parsing (ConfirmationTokenJsonParser)
- Network integration (StripeApiRepository.createConfirmationToken)
- Model serialization (ConfirmationTokenCreateParams)
- Intent confirmation bindings (createWithConfirmationToken methods)

Ready for Week 2-3 milestone: PaymentSheet UI integration

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

…troller

This commit implements Week 2-3 milestone: MPE ConfirmationTokens API integration
following the web Elements auto-collection pattern.

### Key Features:
- **Auto-Collection**: Payment method data, billing details, shipping details automatically collected when user taps "Pay"
- **On-Demand Creation**: ConfirmationTokens created when user submits payment form (web timing pattern)
- **Server-First Architecture**: Mobile collects data, server handles business logic
- **PaymentSheet Integration**: ConfirmationTokenBuilder with callback-based API
- **FlowController Integration**: createConfirmationToken() method for programmatic use

### Components Added:
- ConfirmationTokenCreator: Core token creation logic with auto-collection
- PaymentSheetViewModel: ConfirmationToken mode detection and integration
- DefaultFlowController: createConfirmationToken() method implementation
- PaymentElementCallbacks: Extended with ConfirmationToken callback support
- Dependency Injection: Full DI wiring for both PaymentSheet and FlowController modules

### API Usage:
```kotlin
// PaymentSheet ConfirmationToken mode
val paymentSheet = PaymentSheet.ConfirmationTokenBuilder(callback).build(activity)

// FlowController ConfirmationToken mode
flowController.createConfirmationToken { result -> /* handle result */ }
```

### Auto-Collection Sources:
- Payment method data from PaymentSelection form state
- Billing details from form inputs + configuration defaults
- Shipping details from PaymentSheet configuration
- Setup future usage from user checkbox selection
- Return URL from PaymentSheet configuration

Ready for end-to-end testing with playground activity.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

- Modify PaymentSheetPlaygroundActivity to use ConfirmationTokenBuilder
- Add onConfirmationTokenResult method to handle ConfirmationToken results
- Implement server-side PaymentIntent creation simulation
- Enable end-to-end ConfirmationToken testing in playground

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Move PaymentSheet creation from Compose remember to class-level lazy property
to avoid ActivityResultRegistry registration after Activity RESUMED state.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

- Update server endpoint to use specific IP address (10.0.0.92:8081)
- Add network security configuration to allow cleartext HTTP for development
- Include localhost, 127.0.0.1, and development server IPs in security config
- Enable proper testing of ConfirmationToken flow with local development server

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

This implements a comprehensive ConfirmationToken system that allows merchants to
process payments server-side while maintaining client-side authentication flows.

Key Features:
- Single callback API (`confirmationTokenCallback`) that returns CreateIntentResult
- Always calls confirmationHandler.start() for 3DS and authentication handling
- Unified flow that works with both PaymentSheet and FlowController
- Complete server-side integration support with local development configuration

Technical Implementation:
- Updated ConfirmationTokenCallback to suspend function returning CreateIntentResult
- Simplified PaymentSheet.Builder to remove dual-callback complexity
- Enhanced PaymentSheetViewModel with complete confirmation flow
- Added proper error handling and state management
- Integrated with existing confirmation handler for seamless authentication
- Updated playground with working end-to-end demonstration

Network Configuration:
- Added network security config for local development testing
- Support for localhost, development IPs, and popular tunneling services
- Proper cleartext HTTP handling for development servers

The implementation follows Android SDK patterns and provides a clean developer
experience while maintaining full payment security and authentication capabilities.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>