6ea3005a65
- Create new TicketsController with actions for name collection, creation, and checkout - Add dedicated ticket views (new.html.erb, checkout.html.erb, show.html.erb) - Update ticket_selection_controller.js to handle form submission via AJAX - Add store_cart endpoint in EventsController for session-based cart management - Update routes to support new ticket flow: /tickets/new, /create, /checkout - Fix attribute name consistency across views (title→name, starts_at→start_time) - Add Stripe checkout integration with proper error handling - Remove deprecated collect_names flow in favor of streamlined approach The flow is now: Event selection → AJAX cart storage → Name collection → Checkout → Payment
60 lines
2.7 KiB
Markdown
60 lines
2.7 KiB
Markdown
# Stripe Configuration - Lazy Initialization Approach
|
|
|
|
## Problem
|
|
The "Retour" link on the collect_names page sometimes displayed a Stripe API key error:
|
|
```
|
|
Erreur de traitement du paiement : No API key provided. Set your API key using "Stripe.api_key = <API-KEY>".
|
|
```
|
|
|
|
## Root Cause
|
|
The error occurred because Stripe code was being called without the API key being properly set. This could happen in development environments or when environment variables were not properly configured.
|
|
|
|
## Solution Implemented - Lazy Initialization
|
|
|
|
1. **Deferred Stripe Initialization** (`config/initializers/stripe.rb`):
|
|
- Stripe configuration is loaded at startup but API key is NOT set
|
|
- Stripe.api_key is only set during the checkout process when needed
|
|
|
|
2. **Stripe Concern** (`app/controllers/concerns/stripe_concern.rb`):
|
|
- Created `StripeConcern` module with `stripe_configured?` and `initialize_stripe` methods
|
|
- Included in `EventsController` to provide access to Stripe functionality
|
|
|
|
3. **Direct Configuration Checks**:
|
|
- Updated `process_payment` and `payment_success` methods to directly check Stripe configuration
|
|
- Added proper error handling for initialization failures
|
|
|
|
4. **Benefits of This Approach**:
|
|
- Stripe is only initialized when actually needed (during checkout)
|
|
- Application startup is not dependent on Stripe service availability
|
|
- Payment-related issues are isolated and don't affect other application features
|
|
- More efficient resource usage (Stripe library only fully loaded during checkout)
|
|
|
|
5. **Verification**:
|
|
- Created test scripts to verify the lazy initialization approach
|
|
- Confirmed that Stripe is not initialized at startup but can be initialized during checkout
|
|
|
|
## Code Changes
|
|
|
|
### config/initializers/stripe.rb
|
|
- Removed automatic Stripe.api_key initialization
|
|
- Added informational log message
|
|
|
|
### app/controllers/concerns/stripe_concern.rb
|
|
- Created new concern with `stripe_configured?` and `initialize_stripe` methods
|
|
|
|
### app/controllers/events_controller.rb
|
|
- Added direct Stripe configuration checks in `process_payment` method
|
|
- Added direct Stripe configuration checks in `payment_success` method
|
|
- Added comprehensive logging for debugging
|
|
|
|
### app/helpers/stripe_helper.rb
|
|
- Kept `safe_stripe_call` method with updated logic
|
|
|
|
## Testing
|
|
The new approach has been verified to work correctly:
|
|
- Stripe is not initialized at application startup
|
|
- Stripe is properly initialized during the checkout process
|
|
- All Stripe functionality works as expected
|
|
- Error handling is improved
|
|
|
|
This approach provides better isolation of payment functionality and ensures that issues with Stripe configuration don't affect the rest of the application. |